Azure Active Directory

Azure Active Directory とは

Azure テナント
Azure AD の信頼された専用インスタンスであり、組織が Microsoft Azure、Microsoft Intune、Microsoft 365 などの Microsoft クラウド サービスのサブスクリプションにサインアップしたときに自動的に作成されます。
1 つの Azure テナントは単一の組織を表します。

Azure Active Directory とは

Microsoft が、現在提供しているクラウドベースサービス
・Microsoft Azure
・Microsoft 365
・Microsoft Intune
・Microsoft Dynamics 365

それらのすべてのサービスで、Azure AD を使用して、ユーザーを識別し、アクセスを制御することができる

Azure サブスクリプションと Azure AD の管理者

Azure サブスクリプションと Azure AD には包含関係は無く、独立しています。
Azure サブスクリプションは、必ず 1 つの Azure AD に関連付けられています (*注1) ので、両者の関係性は次のような図になります。

管理者についてもそれぞれ独立していますので、
Azure サブスクリプションの管理者であっても Azure AD の全体管理者でなければ、 Azure AD の管理 (ユーザー追加、削除など) はできません。
同様に Azure AD の全体管理者であっても、必ずしも紐づく Azure サブスクリプションの管理者ではありません。

ID

認証を受けることができるもの。
ID は、ユーザー名とパスワードを持つユーザーの可能性があります。
ID には、秘密キーまたは証明書による認証を必要とする可能性があるアプリケーションまたはその他のサーバーも含まれます

Azure ADで利用できるID

Azure AD アカウント

Azure AD またはそれ以外の Microsoft クラウド サービス (Microsoft 365 など) を通じて作成される ID です。
ID は Azure AD に保存され、組織のクラウド サービスのサブスクリプションで利用できます。
このアカウントは、職場または学校アカウントと呼ばれることもあります。

Azure AD テナント

Azure ADテナントとは

Azure AD テナントは、組織で使用されるアプリケーションとリソースに ID とアクセス管理 (IAM) 機能を提供します。
ID は、リソースへのアクセスを認証および承認できるディレクトリ オブジェクトです。
ID オブジェクトは、学生や教師などの人間の ID、教室や学生のデバイス、アプリケーション、サービスの原則などの人間以外の ID に対して存在します。

Azure ADテナントは、組織の IT 部門の管理下にある ID セキュリティ境界です。 このセキュリティ境界内では、オブジェクト (ユーザー オブジェクトなど) の管理とテナント全体の設定の構成は、IT 管理者によって制御されます。

ディレクトリ、サブスクリプション、およびユーザー

Microsoft が、現在提供しているクラウドベースサービス
・Microsoft Azure
・Microsoft 365
・Microsoft Intune
・Microsoft Dynamics 365

それらのすべてのサービスで、Azure AD を使用して、ユーザーを識別し、アクセスを制御することができる
企業または組織が、これらのサービスの 1 つを使用するためにサインアップすると、
既定の “ディレクトリ”、つまり Azure AD のインスタンスが割り当てられる
この “ディレクトリ”には、企業が購入した各サービスにアクセスできるユーザーとグループが保持される
この既定のディレクトリは、“テナント” と呼ばれる

Azure Active Directory テナントの作成

Microsoft 365 Educationの有料サブスクリプションまたは試用版サブスクリプションにサインアップすると、基になるOffice 365 サービスの一部として Azure Active Directory (Azure AD) テナントが作成されます。
同様に、Azure にサインアップすると、Azure AD テナントが作成されます。
また、Azure portalを使用して Azure AD テナントを手動で作成し、後でOffice 365 サービスを追加することもできます。

Azure ADテナント作成／Azureサブスクリプション契約時に検討すべきこと TAG Azure

Azureの利用する場合、Active Directoryを保有しているかどうかに関わらずAzure ADテナントの作成が必須になります。
これは、Azureで使用するユーザはAzure ADで管理する必要があるためです。
また、実際のAzureリソースはAzureサブスクリプションと呼ばれるAzureアカウント上に作成されますが、このAzureサブスクリプションは必ずAzure ADテナントに紐づいています。

Azure サブスクリプション

Azureテナントはディレクトリであり、ユーザーやグループなどのアイデンティティ情報を管理する単位です。
Azureサブスクリプションは、リソースを配置できる「フォルダー」を表すオブジェクトであり、課金や制限などの設定が可能です。
サブスクリプションはテナントに関連付けられています。
したがって、1つのテナントは多くのサブスクリプションを持つことができますが、その逆はできません。
テナントは単一の ID（個人、会社、または組織）に関連付けられており、1つまたは複数のサブスクリプションを所有できます。

Azure サブスクリプションと Azure AD について

Azure サブスクリプションを Azure Active Directory テナントに関連付けるまたは追加する

すべての Azure サブスクリプションには、Azure Active Directory (Azure AD) インスタンスとの信頼関係があります。
サブスクリプションは信頼された Azure AD に依存して、セキュリティ プリンシパルとデバイスの認証と承認を行います。
サブスクリプションの有効期限が切れると、Azure AD サービスの信頼されたインスタンスは残りますが、セキュリティ プリンシパルでは、Azure リソースへのアクセスができなくなります。
サブスクリプションは 1 つのディレクトリのみを信頼できますが、1 つの Azure AD は複数のサブスクリプションから信頼されることができます

ユーザーが Microsoft のクラウド サービスに新規登録すると、新しい Azure AD テナントが作成され、そのユーザーは全体管理者ロールに属します。
ただし、サブスクリプションの所有者が自分のサブスクリプションを既存のテナントに参加させるとき、その所有者は全体管理者ロールに割り当てられません。

AzureサブスクリプションとかアカウントとかAzure ADのテナントとか (1)

Azure ADテナントとは？課金の仕組みや運用方法を解説

Azure AD ロール

Azure Active Directory のロールについて

ディレクトリ内の Azure AD リソースの管理に使用されます。
たとえば、
ユーザーの作成や編集、
他のユーザーへの管理ロールの割り当て、
ユーザー パスワードのリセット、
ユーザー ライセンスの管理、
ドメインの管理など

各ロールの関係

Azure ロールと Azure AD ロールの違い

Azure AD の組み込みロール

パスワードをリセットできるロール

グローバル管理者

グローバル管理者

グローバル閲覧者

グローバル閲覧者

このロールのユーザーは、Microsoft 365 の各サービスにわたって設定と管理情報を読み取ることができますが、管理アクションを実行することはできません。 グローバル閲覧者は、全体管理者に対応する読み取り専用のロールです。

特権ロール管理者

グローバル管理者を含む Azure AD の特権ロール付与や Privileged Identity Management (PIM) 機能を管理することができる

特権ロール管理者

グループ管理者

グループ管理者

このロールのメンバーは、グループの作成と管理、名前付けと有効期限ポリシーなどのグループ設定の作成と管理、グループのアクティビティと監査レポートの表示を行うことができます。

セキュリティ管理者

セキュリティ管理者

次のセキュリティ関連機能を管理するアクセス許可あり
Microsoft 365 Defender ポータル、Azure Active Directory Identity Protection、Azure Active Directory Authentication、Azure Information Protection、Microsoft Purview コンプライアンス ポータル

セキュリティ オペレーター

セキュリティ閲覧者

パスワード管理者

パスワード管理者

管理者以外とパスワード管理者のパスワードをリセットできます。

認証管理者

認証管理者

アプリケーション管理者

アプリケーション管理者

このロールのユーザーは、エンタープライズ アプリケーション、アプリケーション登録、アプリケーション プロキシの設定の全側面を作成して管理できます。

アプリケーション開発者

アプリケーション開発者

このロールのユーザーは、
[ユーザーはアプリケーションを登録できる] 設定が [いいえ] に設定されている場合に、アプリケーション登録を作成できる。
[ユーザーはアプリが自身の代わりに会社のデータにアクセスすることを許可できる] 設定が [いいえ] に設定されている場合に、代わりに同意する権限を付与します。
新しいアプリケーション登録を作成する際に、所有者として追加されます。

クラウド アプリケーション管理者

クラウド アプリケーション管理者

このロールのユーザーは、(アプリケーション プロキシを管理する権限を除き) アプリケーション管理者ロールと同じアクセス許可を持ちます

課金管理者

課金管理者

購入、サブスクリプションの管理、サポート チケットの管理、サービスの正常性の監視

カスタム ロール

Azure AD のリソースに対するアクセス許可を管理するためのカスタムロール

Azure Active Directory のロールベースのアクセス制御の概要

Azure portal を使用して Azure カスタム ロールを作成または更新する

カスタム ロールの作成を開始するには、次の 3 つの方法
・ロールを複製
・最初から行う
・JSON から始める

ロールを複製する

１．Azure portal で、カスタム ロールを割り当て可能にするサブスクリプションまたはリソース グループを開き、 [アクセス制御 (IAM)] を開きます。
⒉．[ロール] タブをクリックして、すべての組み込みおよびカスタム ロールの一覧を表示
　　複製するロールを検索

Azure Active Directory でカスタム ロールを作成して割り当てる

Azure Active Directory>[ロールと管理者]>[新しいカスタム ロール]

ベスト プラクティス

Azure AD ロールのベスト プラクティス

Azure Active Directory のタスク別の最小特権ロール

Azure AD グループ

2 種類のグループと 3 種類のグループ メンバーシップがあります

Azure Active Directory のグループとアクセス権の詳細

Azure AD管理センターの内容解説【MicrosoftのMVP解説！第三弾 Microsoft 365の活用術】

Azure AD グループを使用してロールの割り当てを管理する

グループにロールを割り当てるには、isAssignableToRole プロパティが true に設定された新しいセキュリティ グループまたは Microsoft 365 グループを作成する必要があります

Azure AD グループを使用してロールの割り当てを管理する

グループの入れ子化はサポートされていません。 グループは、ロール割り当て可能なグループのメンバーとして追加することはできません。

セキュリティ グループ

グループの種類

セキュリティ: 共有リソースに対するユーザーとコンピューターのアクセスを管理するために使います

たとえば、セキュリティ グループを作成し、グループの全メンバーに同じセキュリティ アクセス許可セットが付与されるようにすることができます。
セキュリティ グループのメンバーには、ユーザー、デバイス、他のグループ、サービス プリンシパルを含めることができます。これにより、アクセス ポリシーとアクセス許可を定義します。
セキュリティ グループ所有者には、ユーザーとサービス プリンシパルを含めることができます。

Microsoft 365 グループ

グループの種類

Microsoft 365: 共有メールボックス、カレンダー、ファイル、SharePoint サイトなどへのアクセス権をグループ メンバーに付与することで、共同作業の機会を提供します

組織外のユーザーにグループへのアクセス権を付与することもできます。
Microsoft 365 グループのメンバーには、ユーザーのみを含めることができます。
Microsoft 365 グループ所有者には、ユーザーとサービス プリンシパルを含めることができます

Azure Active Directory で削除された Microsoft 365 グループを復元する

Azure Active Directory (Azure AD) で Microsoft 365 グループを削除すると、削除されたグループは表示されなくなりますが、削除日から 30 日間は保持されます。
この動作は、必要に応じて、グループとその内容を復元できるようにするためです。 この機能は、Azure AD の Microsoft 365 グループに限定されます。

名前付けポリシー

グループの名前付けポリシーとは、ユーザーが作成するグループの名前に一貫性を持たせるための機能です。
プレフィックスやサフィックスを使って、グループの役割やメンバー、地域などを表現できます。また、不適切な単語の使用をブロックすることもできます

名前付けポリシーは、Microsoft 365 グループに適用されます。
これには、Outlook、Microsoft Teams、SharePoint、Planner、Yammer などのグループ ワークロードが含まれます。
配布グループにも名前付けポリシーを適用できます。

Azure Active Directory での Microsoft 365 グループに対する名前付けポリシーの適用

名前付けポリシーは、全体管理者やユーザー管理者などの特定のディレクトリ ロールには適用されません
既存の Microsoft 365 グループの場合、ポリシーは構成時にすぐには適用されません。 グループ所有者がこれらのグループのグループ名を編集すると、変更が行われていなくても、名前付けポリシーが適用されます。

動的グループ

Azure Active Directory で動的グループを作成または更新する

Azure Active Directory の動的グループ メンバーシップ ルール

Azure ADの動的なグループメンバーシップ設定

メンバーシップ

メンバーシップの種類

割り当て済み

特定のユーザーをグループのメンバーとして追加し、固有のアクセス許可を付与することができます

動的ユーザー

動的メンバーシップ ルールを使用して、メンバーを自動的に追加および削除できます

動的デバイス

動的なグループ ルールを使用して、自動的にデバイスを追加および削除できます

Azure AD ユーザー

ユーザーの作成と管理

Azure リソースへのアクセスを必要とするすべてのユーザーには、Azure ユーザー アカウントが必要

Azure Active Directory を使用して最近削除されたユーザーを復元または削除する

ユーザーを削除した後、アカウントは 30 日間、中断状態のままになります。
その 30 日の期間中は、ユーザー アカウントをそのすべてのプロパティと共に復元することができます。

クラウド ID

このカテゴリのユーザーは、Azure AD 内にのみ存在し、他のオンプレミス AD サーバーには存在しません。
これらのユーザーのソースは Azure AD になります。

ディレクトリ同期 ID

このカテゴリのユーザーは、Azure クラウド環境に取り込む予定のオンプレミス AD に元々存在していた。
これを行うには、Azure AD Connect を利用した同期アクティビティを使用して、これらのユーザーを Azure AD に取り込み、オンプレミスと AD のクラウド インスタンスの両方に存在できるようにします。

ゲスト ユーザー

これらのユーザーは Azure の外部に存在します。
例として、他のクラウド プロバイダーのアカウント、Xbox LIVE アカウントなどの Microsoft アカウントがあります。
そのソースは、招待されたユーザーです。
この種類のアカウントは、外部ベンダーや請負業者が Azure リソースへのアクセスを必要とする場合に便利です。
ヘルプが不要になったら、アカウントとすべてのアクセス権を削除できます。

ユーザー プリンシパル名

Azure AD の UserPrincipalName の設定

UserPrincipalName は、インターネット標準 RFC 822 に基づく属性で、ユーザーのインターネット形式のログイン名となります。

Azure AD へのユーザーの追加方法

Azure Active Directory でのユーザーの一括作成

必須値は、 [名前] 、 ユーザー プリンシパル名 、 [初期パスワード] 、および [サインインのブロック (はい/いいえ)] のみ

オンプレミス Windows Server AD の同期

Azure ポータル

コマンドライン ツール

他のオプション

管理単位

Azure Active Directory の管理単位

Azure ADでOUを作成

外部 ID

Azure Active Directory の External Identities

B2B コラボレーション

外部ユーザーが自分の好みの ID を使用して Microsoft アプリケーションや他のエンタープライズ アプリケーション (SaaS アプリ、カスタム開発アプリなど) にサインインすることで、外部ユーザーと共同作業を行います。 B2B コラボレーション ユーザーはディレクトリで表され、通常はゲスト ユーザーとして表示されます。

外部コラボレーション

Azure Active Directory (Azure AD) を使用して、組織外のユーザーと協力して作業できる機能
外部コラボレーションの設定を有効にすると、ゲストユーザーを招待したり、特定のドメインを許可したりブロックしたり、ゲストユーザーのアクセス権限を制限したりすることができます

外部コラボレーションの設定を構成する

ハイブリッド ID

Azure Active Directory (Azure AD) をオンプレミスの AD と同期することで、従業員の ID の管理を一元化できます。

Azure Active Directory でのハイブリッド ID とは

3 つの認証方法のうち 1 つを使用できます。 次に 3 つの方法を示します。
- パスワード ハッシュの同期 (PHS)
- パススルー認証 (PTA)
- フェデレーション (AD FS)

これらの認証方法でも、シングル サインオン機能が提供されます

Azure Active Directory ハイブリッド ID ソリューションの適切な認証方法を選択する

Azure AD のパスワード ハッシュ同期
Azure AD でオンプレミスのディレクトリ オブジェクトの認証を有効にする最も簡単な方法
ユーザーはオンプレミスで使用しているものと同じユーザー名とパスワードを使用できる
追加のインフラストラクチャを展開する必要はない

Azure AD パススルー認証
1 つ以上のオンプレミス サーバーで実行されているソフトウェア エージェントを使用して、Azure AD 認証サービスに簡単なパスワード検証を提供する
オンプレミスの Active Directory を使用してサーバーで直接ユーザーが検証され、クラウドでパスワードの検証が行われることはない
オンプレミスのユーザー アカウントの状態、パスワード ポリシー、およびサインイン時間をすぐに適用するセキュリティ要件のある企業は、この認証方法を使用する

フェデレーション認証
Azure AD は別の信頼された認証システム (オンプレミスの Active Directory フェデレーション サービス (AD FS) など) に、ユーザーのパスワードを検証する認証プロセスを引き継ぐ

Azure AD Connect

Azure AD Connect とは

Azure AD Connect を使用する理由

Azure AD Connect:アカウントとアクセス許可

Azure AD Connect に使用されるアカウント

簡単設定を使用したインストール

Azure AD 全体管理者の資格情報

Azure AD 全体管理者アカウントに対する資格情報は、インストール中にのみ使用されます。
このアカウントは、Azure AD に変更を同期する Azure AD コネクタ アカウントを作成するために使用します。
また、このアカウントにより、同期が Azure AD の機能として有効化されます。

AD DS エンタープライズ管理者の資格情報

AD DS エンタープライズ管理者アカウントは、Windows Server AD の構成に使用されます。 これらの資格情報が使用されるのは、インストール中のみです。
ドメイン管理者ではなく、エンタープライズ管理者が、すべてのドメインで Windows Server AD 内のアクセス許可が設定できることを確認する必要があります。

DirSync からアップグレードする場合は、
AD DS エンタープライズ管理者の資格情報を使用して、DirSync で使用されていたアカウントのパスワードをリセットします。
Azure AD グローバル管理者の資格情報も必要になります。

Azure AD Connectを使ってアカウントを同期する方法

同期規則エディター

Azure AD Connect 同期 の 既定の構成 を表示したり変更したりするツール

Azure AD Connect 同期: 既定の構成に変更を加える

フィルター処理

Azure AD Connect 同期: フィルター処理の構成

フィルター処理を使用することによって、オンプレミスのディレクトリからどのオブジェクトを Azure Active Directory (Azure AD) に反映するかを制御できる

フィルター処理オプション

フィルター処理オプション

属性ベース

オブジェクトの属性値に基づいてオブジェクトをフィルター処理
オブジェクトの種類ごとに異なるフィルターを使用することもできる

Azure AD Connect Health

認証

Azure Active Directory ハイブリッド ID ソリューションの適切な認証方法を選択する

パスワード ハッシュ同期

Azure AD とのパスワード ハッシュ同期とは

Azure AD Connect は、オンプレミスの Active Directory インスタンスからクラウドベースの Azure AD インスタンスに向けて、ユーザーのパスワードのハッシュと同期します。

詳細な考慮事項

パスワード ハッシュ同期は、展開、メンテナンス、インフラストラクチャに関して最小の作業量

パススルー認証

Azure Active Directory パススルー認証とは

Azure Active Directory (Azure AD) パススルー認証を使用すると、ユーザーは同じパスワードを使用して、オンプレミスのアプリケーションとクラウド ベースのアプリケーションの両方にサインインできます。

詳細な考慮事項

フェデレーション

Azure AD とのフェデレーションとは

詳細な考慮事項

信頼できる外部システムを利用してユーザーを認証する
フェデレーション システムへの既存の投資を Azure AD ハイブリッド ID ソリューションで再利用できる

Azure AD でシングル サインオン！！　～フェデレーション編～

Privileged Identity Management

特権ロールが必要になったとき、利用者側の要求に従って、特定の時間だけ特権ロールを付与することができる

Azure AD Privileged Identity Management とは

Privileged Identity Management (PIM) は、お客様の組織内の重要なリソースへのアクセスを管理、制御、監視することができる

Privileged Identity Management で拒否された Azure リソースへのアクセスのトラブルシューティング

Privileged Identity Management サービスから Azure リソースへのアクセスができるようにするには、Azure サブスクリプションで MS-PIM サービス プリンシパルにユーザー アクセス管理者ロールが常に割り当てられている必要があります。

1.1.4. Azure AD Pricileged Identity Management

PIMの主な機能の確認

・ JIT（Just-In-Time）によって、作業時のみ権限を割り当てる。これは0.5～24時間まで
・ リソースへの期限付きアクセス（権限を割り当てる際にあらかじめ有効期間を設定する）
・ その権限を有効にするための承認プロセス
・ 特権アカウントを使用する際に、MFAを確実に使用（全ユーザーがMFAを使用している場合＜すでにMFAにてログインしている＞は再度サインインする必要なし）
・ そのアカウントのロールが必要な理由を明確化する。これによって、監査が容易になります。
・ 特権アカウントが割り当てられた際の通知
・ アクセスレビューによる、特権アカウントの割り当て把握
・ 監査履歴をしようすることで、PIMイベントを継続的に追跡可能。外部監査にも利用できる。

Azure AD グループ + PIM で特権ロールを管理してみた！

Privileged Identity Management (PIM) を使って Azure の権限管理をやってみた

主な特徴としては、特権ロールが必要ないときは、利用者に必要最低限のロールを付与しておき、特権ロールが必要になったとき、利用者側の要求に従って、特定の時間だけ特権ロールを付与することができます。管理者は能動的に利用者に権限付与をするのではなく、利用者からの要求に従って、必要な時間だけ必要な特権ロールを付与することができるようになります。

PIMサービスの概要と画面イメージの紹介

普段使いのロールを割当てる際には「Active」タイプのロールを割当てて、
特権ロールに関しては「Eligible」で割当てる（特権ロールを申請する資格がある）

Azure AD Privileged Identity Management で管理者権限の利用を制御する

ロールの設定

Privileged Identity Management で Azure AD ロールの設定を構成する

Azure AD ロールの PIM ロール設定を管理するには、グローバル管理者または特権ロール管理者ロールが必要です。
ロール設定は、ロールごとに定義されます。
同じロールに対するすべての割り当ては、同じロール設定に従います。
あるロールのロール設定は、別のロールのロール設定とは独立しています。

アクティブ化の最大期間

ロールの割り当てのアクティブ化要求が、有効期限が切れるまでアクティブなままである最大時間 (時間単位)

アクティブ化の際に多要素認証を要求する

アクティブ化の正当な理由を要求する

アクティブ化時にチケット情報を要求する

アクティブ化の承認を必須にする

割り当て期間

アクティブな割り当てに対して多要素認証を要求する

アクティブな割り当ての理由を要求する

Azure AD Privileged Identity Management で管理者権限の利用を制御する

割り当て

ロールの割り当ての概要

割り当て

Azure AD Privileged Identity Management で管理者権限の利用を制御する

Active（アクティブ）

この種類のロールを割当てられたユーザーは、
アクティベーションの操作を必要とせずに、そのロールが常にアクティブ化される。

Eligible（有資格）

この種類のロールを割当てられたユーザーは、
そのロールをアクティベートする資格を有しており、
アクティベートすることによって、最大24時間そのロールをアクティブ化することができる。

アクティブ化

アクティブ化

ユーザーが有資格の割り当てを持っている場合は、ロールを使用する前にロールの割り当てをアクティブにする必要がある
ロールをアクティブにするには、ユーザーは最大範囲 (管理者が設定) 内で特定のアクティブ化期間と、アクティブ化要求の理由を選択する

PIMサービスの概要と画面イメージの紹介

申請者はAzure Portalから特権ロールを申請(アクティブ化)します。
※申請者は申請する資格を有する、つまり該当ロールがEligibleタイプで割り当てられていることが前提条件です。

MFAの要求

アクティブ化時

ロールの割り当てをアクティブ化するために多要素認証を要求するには、 Edit role setting の アクティブ化 タブで On activation, require Azure MFA を選択

Azure AD Privileged Identity Management で管理者権限の利用を制御する

要求の承認

要求の承認

承認者は自分自身のロールのアクティブ化要求を承認できません。

特権アクセスグループ

Privileged Identity Management に特権アクセス グループ (プレビュー) を持ち込む

管理するグループを識別する

Azure AD でロールを割り当て可能なグループを作成できます。
グループを Privileged Identity Management で管理するには、
グループの所有者のロール、または
グローバル管理者のロール、または
特権ロール管理者のロール
に設定されている必要があります。

セキュリティ アラート

Privileged Identity Management で Azure AD ロールに対するセキュリティ アラートを構成する

Microsoft Entra Identity Governance

Identity Governanceは、「適切なユーザーに」 「適切なアクセス権を」 「適切な期間のみ」 を実現するもの

Identity Governance を設計する

アクセス レビュー

Microsoft 365 を利用するにあたり、グループメンバーの管理やアプリケーション連携、管理者ロールの割り当て変更など、様々な管理業務が定期的に発生
日々適切な管理ができていれば問題ないが、完全自動化されていない限り、
うっかり権限を変更しないまま運用したり、所属しているグループのメンバーが把握しきれていない状態になったりしてしまう可能性もある。
過剰な権限を与えたままでは、資格情報の流出による Microsoft 365 への侵入などのリスクも考えられる
管理者は、不必要な権限を削除し、適切なグループ管理を行うよう、適宜確認して運用することが望ましい

「アクセス レビュー」は、所謂「棚卸し」の機能で、グループやアプリに対するユーザーのアクセス状況が確認できる
不要なメンバーや権限を効率的に削除することが可能

アクセス レビューとは

アクセス レビューが重要である理由

アクセス レビューを使用すべきとき

レビューを作成する場所

「アクセスレビュー」で、グループやアプリ、管理者ロールを効率的に管理

Azure AD でグループとアプリケーションのアクセス レビューを作成する

PIM で Azure リソース ロールと Azure AD ロールのアクセス レビューを作成する

Azure AD でグループとアプリケーションのアクセス レビューを作成する

Microsoft Entra アクセス レビューの展開を計画する

レビューが可能なリソースの種類は?

アクセス レビューを作成および管理するのは誰か?

アクセス レビューの計画を立てる

レビュー担当者

リソースへのアクセスをレビューするのは誰か?

誰がレビューを行うかは、アクセス レビューの作成者が作成時に決定します。
この設定は、レビューが開始した後は変更できません。
‣リソースのビジネス オーナーであるリソース所有者。
‣アクセス レビューの管理者によって個別に選択された委任。
‣継続的なアクセスの必要性を各自で自己証明するユーザー。
‣マネージャーは、直属の部下によるリソースへのアクセスをレビューします。

グループとアプリのアクセス レビューを作成する

[レビュー担当者を選択する] セクションで、アクセス レビューを実行する人を 1 人以上選択します。 次の項目から選択できます。
- グループ所有者 (チームまたはグループに対するレビューを実行する場合のみ使用可能)
- Selected user(s) or groups(s) (選択したユーザーまたはグループ)
- Users review own access (ユーザーが自分のアクセスを確認する)
- (プレビュー) Managers of users (ユーザーの管理者)。 Managers of users または [グループ所有者] を選択した場合は、フォールバック レビュー担当者を指定することもできます。 フォールバック レビュー担当者は、そのユーザーの管理者がディレクトリで指定されていないか、またはそのグループに所有者がいない場合にレビューを実行するよう求められます。

条件付きアクセス

条件付きアクセスとは、Azure AD への認証に対して、制限対象 (割り当て)に該当するユーザーを許可 or 拒否 (アクセス制御)する事ができる機能です。
これは、Azure AD の「認証」と「認可」に対して、アクセス条件を追加する機能です。

Azure AD の条件付きアクセスの設定手順は次のとおりです。
1.Azure portal に、条件付きアクセス管理者、セキュリティ管理者、または全体管理者としてサインインします。
2.[Azure Active Directory][セキュリティ]条件付きアクセス の順に移動します。
3.[新しいポリシー] を選択します。
4.ポリシーに名前を付けます。

条件付きアクセスとは

条件付きアクセスのデプロイを計画する

条件付きアクセス ポリシー

条件付きアクセス ポリシーは、ユーザーがリソースにアクセスする場合に、ユーザーはアクションを完了する必要があるという if-then ステートメント
例: 給与管理者は、給与処理アプリケーションにアクセスしようとする場合、多要素認証を実行することが要求される

条件付きアクセスポリシー(CA)

CAのポイント
- CAポリシーに優先順位という概念はない
- すべてのポリシーが評価され、割り当て条件に合致したサインインイベントに対し、制御がすべて適用される
- 許可よりもブロックが勝つ

条件付きアクセスの基本的な考え方

割り当て

ユーザーとグループ
クラウドアプリ
条件
場所

場所

【Azure】条件付きアクセスの設定方法解説！【ポータルへのアクセスをIPアドレスで制限する】

許可するIPアドレスの指定
「ネームド ロケーション」＞「新しい場所」

アクセス制御

許可
アクセスのブロック

アクセスのブロック

アクセス権の付与

アクセス権の付与

多要素認証

[多要素認証を要求する]

条件付きアクセスによるMFA有効化

条件付きアクセスを利用することでユーザーが増えた場合でも、自動的にMFAを適用することが可能

多要素認証を要求されたら

Office 365 の多要素認証(MFA)を有効化

セッション

ポリシー 1:サインイン頻度コントロール

レポート専用モード

条件付きアクセス ポリシーの影響を評価するために使用できるモードです。
レポート専用モードでは、ポリシーが適用された場合にどのような結果になるかをレポートとして確認できますが、実際にはポリシーは強制されません。

条件付きアクセスのレポート専用モードとは

管理者が環境で条件付きアクセス ポリシーを有効にする前に、その影響を評価することができる

認証

認証方法ポリシー

認証方法ポリシー

Azure 認証方法ポリシーでは、ユーザーが Azure Active Directory (Azure AD) にサインインする際に使用できる認証方法を管理できる

パスワードレス認証オプション

Azure Active Directory のパスワードレス認証オプション

Windows Hello for Business
Microsoft Authenticator
FIDO2 セキュリティ キー

パスワード保護

Azure Active Directory パスワード保護を使用して不適切なパスワードを排除する

パスワードの評価方法

ユーザーが自分のパスワードを変更またはリセットすると、
グローバルとカスタムの禁止パスワード リストから結合された用語リストに対して新しいパスワードを検証することで、その強度と複雑さがチェックされます。

オンプレミスの Azure Active Directory パスワード保護を計画してデプロイする

監査モード

監査モード

現在のポリシーが監査モードに構成されている場合、“不正な” パスワードは、イベント ログ メッセージが生成される原因となりますが、処理されて更新されます。

強制モード

強制モード

強制モードが有効になっている場合は、ポリシーに従って安全でないと見なされたパスワードは拒否されます。

多要素認証

Azure Active Directory の多要素認証のデプロイを計画する

チュートリアル:Azure AD Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する

Azure AD Multi-Factor Authentication の設定を構成する

演習 - Azure AD Multi-Factor Authentication の有効化

Azure AD Multi-Factor Authentication におけるユーザーの状態

統合された登録

Azure Active Directory での統合されたセキュリティ情報の登録の概要

Azure Active Directory での統合されたセキュリティ情報の登録の有効化

統合された登録を有効にするには、次の手順に従います。
Azure portal に ユーザー管理者 または 全体管理者 としてサインインします。

ユーザーは１回登録でMFAとSSPRの両方を利用できますか。

ユーザーは 1 回登録して Azure AD Multi-Factor Authentication (MFA)とセルフサービス パスワード リセット(SSPR)の両方の利用が可能です。
統合される前、ユーザーは Azure AD Multi-Factor Authentication (MFA) とセルフサービス パスワード リセット (SSPR) の認証方法を別々に登録しましたが、2020年8月15日の以降は、すべての新しい Azure AD テナントで、統合された登録が自動的に有効になりました。

Identity Protection

Identity Protection を使用して組織内の ID のリスクを特定し、対処する

Identity Protection とは

必要なロール

ライセンスの要件

Azure AD Premium P2 ライセンスが必要

Identity Protection は Microsoft が持つ脅威の検出ソリューションの一つで
Azure Advanced Threat Protection や Microsoft Cloud App Security と連携し ID に関するリスクを検出 /管理 / 保護することができます。

Azure AD Identity Protection をデプロイする

Azure AD Identity Protectionのリスク検出を試してみた

1.1.3. Azure AD Identity Protection

アクセスロール

必要なロール

サインイン リスク

サインイン リスク

ユーザー リスク

Identity Protection では、ユーザーの標準的な行動であると確信できるものは何かを判断し、それを使用してユーザーのリスクに関する意思決定を行うことがでる
“ユーザー リスク” とは、ID が侵害されている 確率の計算
管理者は、このリスク スコア信号に基づいて、組織の要件を適用するかどうかを決定できる

リスク レベル

リスク レベル

Identity Protection では、リスクを低、中、高の複数のレベルに分類

ポリシー作成の最初のステップとして、アラートをトリガーする Identity Protection のレベルを選択する必要があります。
Microsoft の推奨事項は、ユーザー ポリシーのしきい値を高に設定し、サインイン リスク ポリシーを中以上に設定し、自己修復オプションを有効にすることです。

リスク ポリシー

リスクベースのアクセス ポリシー

リスク ポリシーを構成して有効にする

Azure Active Directory (Azure AD) の条件付きアクセスには、リスクへの対応を自動化し、リスクが検出されたときにユーザーが自己修復できるようにするために設定できる、2 種類のリスク ポリシーがあります。

割り当て で、 [ユーザーまたはワークロード ID] を選択します。
Include で、 [すべてのユーザー] を選択します。
[除外] で、 ユーザーとグループ を選択し、組織の緊急アクセス用または非常用アカウントを選択します。

Identity Protection 2 つのリスク ポリシーの導入メリットについて

サインイン リスク ポリシー

不審なサインイン試行を識別して対処
Azure AD Multi-Factor Authentication を使用して追加の検証フォームを提供するようユーザーに求めることができます。

サインイン リスクベースの条件付きアクセス ポリシー

次のような要件を含むサインイン リスクに基づいてアクセス制御を適用できます。
アクセスのブロック
アクセスを許可
多要素認証を要求する

注意
サインイン リスク ポリシーをトリガーする前に、ユーザーは Azure AD Multifactor Authentication に事前に登録しておく必要があります。

サインイン リスク ポリシーを実装する

Azure ADのIdentity Protectionを設定する

「低以上」だと検知の頻度が多くなる可能性があるので、MS推奨は「中以上」です。

一般的な条件付きアクセス ポリシー: サインイン リスク ベースの多要素認証

このポリシーを構成できる場所は 2 つあります。1 つは条件付きアクセスで、もう 1 つは Identity Protection です。

ユーザーが MFA に登録されていない場合、危険なサインインがブロックされ、AADSTS53004 エラーが表示されます。

ユーザー リスク ポリシー

資格情報が侵害された可能性のあるユーザー アカウントを識別して対処
ユーザーに新しいパスワードの作成を促すことができる

ユーザー リスク ポリシーを実装する

管理者は、
- アクセスをブロックする
- アクセスを許可する
- アクセスを許可するが Azure AD のセルフサービス パスワード リセット を使用してパスワードを変更する必要がある
ことを選択できます。

Azure ADのIdentity Protectionを設定する

多要素認証登録ポリシー

ユーザーが Azure AD Multi-Factor Authentication に登録されているかどうかを確認
サインイン リスク ポリシーによって MFA を要求する場合は、ユーザーが Azure AD Multi-Factor Authentication に既に登録されている必要がある

方法: Azure AD 多要素認証登録ポリシーを構成する

レポート

危険なユーザー

危険なユーザー レポートによって提供される情報を使用して、管理者は、以下を見つけることができる
- どのユーザーにリスクがあり、リスクが修復されたか無視されたか
- 検出の詳細
- すべての危険なサインインの履歴
- リスクの履歴

管理者は、これらのイベントに対するアクションを選ぶことができる
- ユーザー パスワードをリセットする
- ユーザーの侵害を確認する
- ユーザー リスクを無視する
- ユーザーによるサインインをブロックする
- Azure ATP を使用してさらに調査する

リスクの高いサインイン

リスク検出

アプリケーション管理

Azure Active Directory でのアプリケーション管理とは

Azure ADのアプリケーション管理は、クラウドでアプリケーションを作成、構成、管理、および監視するプロセスです。
アプリケーションが Azure AD テナントに登録されると、そのアプリケーションに割り当てられているユーザーは安全にアクセスできます。
さまざまな種類のアプリケーションを Azure AD に登録できます。

Microsoft ID プラットフォーム

認証

認証と承認

OAuth 2.0

Microsoft ID プラットフォームにおける OAuth 2.0 と OpenID Connect (OIDC)

Microsoft ID プラットフォームと OAuth 2.0 認証コード フロー

Microsoft ID プラットフォームと暗黙的な許可のフロー

OAuth 2.0 コード付与フローを使用して Azure Active Directory Web アプリケーションへアクセスを承認する

アプリケーション登録

Azure Active Directory のアプリケーション オブジェクトとサービス プリンシパル オブジェクト

アプリケーションの登録

ID とアクセスの管理機能を Azure AD に委任するには、アプリケーションを Azure AD のテナントに登録する必要がある
アプリケーションを Azure AD に登録するときに、アプリケーションの ID 構成を作成する。これによって Azure AD との連携が可能となる。
Azure portal でアプリを登録するときに、それがシングル テナントかマルチテナントかを選択し、必要に応じて リダイレクト URI を設定する。

ポータルでアプリケーションを登録すると、ホーム テナント に アプリケーション オブジェクト と サービス プリンシパル オブジェクト が 自動的に 作成される。
Microsoft Graph API を使用してアプリケーションを登録または作成する場合、サービス プリンシパル オブジェクトの作成は別の手順。

Azure ADのアプリの登録とは

AD テナントへのアプリケーションの登録

アプリケーションを Azure AD に追加する方法と理由

アプリケーションを Azure AD と統合する理由

アプリケーションは、Azure AD が提供するサービスを利用するために Azure AD に登録される

「ユーザーはアプリケーションを登録できる」の設定について

Azure Active Directory の [ユーザー設定] で、「ユーザーはアプリケーションを登録できる」を「いいえ」に変更することによって、一般ユーザーによるアプリの登録を行えなくすることが可能

サービス プリンシパル

サービス プリンシパル オブジェクト

【Azure】サービスプリンシパルを整理しよう

AzureADに作成したアプリケーションのID・パスワードの認証を委任することができる機能

アプリケーション所有権

Azure Active Directory のエンタープライズ アプリケーション所有権の概要

アクセス管理

アクセス許可

アクセス許可と同意の概要

委任されたアクセス許可

委任アクセス (ユーザーの代わりにアクセス)

ユーザーがクライアント アプリケーションにサインインしています。
クライアント アプリケーションは、ユーザーの代わりにリソースにアクセスします。
委任アクセスでは、委任されたアクセス許可が必要です。

アプリケーションのアクセス許可

アプリ専用のアクセス (ユーザーが関与しないアクセス)

ユーザーがサインインしていない状態でアプリケーションが単独で動作します

アプリケーションへのアプリ ロールの割り当て

アプリケーションにアプリ ロールを割り当てるときは、“アプリケーションのアクセス許可” を作成します。
通常、アプリケーションのアクセス許可は、認証および承認された API 呼び出しをユーザーによる操作なしで行う必要がある、デーモン アプリまたはバックエンド サービスによって使用されます。

Microsoft Graph にアクセスするためのアクセス許可を追加する

同意

アプリケーションにアクセス権を付与することを、リソース所有者が “承認”する

アクセス許可と同意の概要

Azure Active Directory におけるユーザーと管理者の同意

管理者の同意ワークフローの構成

管理者の同意ワークフローを有効にするには、グローバル管理者である必要があります

アプリケーションに対してテナント全体の管理者の同意を付与する

グローバル管理者または特権ロール管理者：任意の API に対してアクセス許可を要求するアプリに同意を付与
クラウド アプリケーション管理者またはアプリケーション管理者：任意の API に対してアクセス許可を要求するアプリに同意を付与

ユーザーの同意
管理者の同意
事前承認

ユーザー割り当て

アプリケーションにユーザーとグループを割り当てる

アプリケーションにユーザーを割り当てると、そのアプリケーションが、簡単にアクセスできるようにユーザーの マイ アプリ ポータルに表示されます。
アプリケーションでアプリ ロールが公開されている場合は、ユーザーに特定のアプリ ロールを割り当てることもできます。

グループをアプリケーションに割り当てると、そのグループ内のユーザーのみがアクセスできるようになります。
割り当ては、入れ子になったグループにはカスケードされません。

グループベースの割り当てには、Azure Active Directory Premium P1 または P2 エディションが必要です。
グループ ベースの割り当てがサポートされるのはセキュリティ グループのみです。
入れ子になったグループ メンバーシップと Microsoft 365 グループは、現在サポートされていません。

マイ アプリ

マイ アプリ ポータルの概要

マイ アプリは、Azure Active Directory (Azure AD) でアプリケーションを管理および起動するために使用される Web ベースのポータル
マイ アプリでアプリケーションを操作するには、Azure AD の組織アカウントを使用し、Azure AD管理者によって付与されるアクセス権を取得

セルフサービス アプリケーション

Azure AD でユーザーをアプリケーションに割り当てる方法

管理者が [アプリケーションのセルフ サービス アクセス] を有効にして、ビジネス承認なしでユーザーがマイ アプリの [アプリの追加] 機能を使用してアプリケーションを追加することを許可します

セルフサービス アプリケーションの割り当てを有効にする

セルフサービス アクセス

アクセス権は、テナント レベルで付与したり、特定のユーザーに割り当てたり、セルフサービス アクセス から付与したりできます。
ユーザーが マイ アプリ ポータル から自分でアプリケーションを見つけられるようにするには、Azure portal で セルフサービス アプリケーション アクセスを有効 にします。

従業員エンパワーメントを促進してヘルプ デスク問い合わせを減らす

マイ アプリ ポータル

マイ アプリ ポータルは、Azure Active Directory (Azure AD) のマイ アプリと呼ばれるWebベースのポータルで、アプリの起動と管理を行うために使用されます。
このページを使用すると、ユーザーは1か所で作業を開始し、アクセスできるすべてのアプリケーションを見つけることができます。

マイ アプリ ポータルの概要

SAML トークン暗号化

SAML トークン暗号化は、ID プロバイダーとサービス プロバイダー間で認証および認可データを交換するためのオープン標準である Security Assertion Markup Language (SAML) を使用して、Azure AD が発行する SAML トークンを暗号化する機能
SAML トークン暗号化を構成するには、次の手順が必要です。
- アプリケーションで構成されている秘密キーに一致する公開キー証明書を取得します。
- Azure AD のアプリケーション構成に証明書を追加します。
- アプリケーションの SAML 設定でトークン暗号化を有効にします。

Azure Active Directory の SAML トークン暗号化を構成する

トークン暗号化を構成するには、公開キーを含んだ X.509 証明書ファイルを、アプリケーションを表す Azure AD アプリケーション オブジェクトにアップロードする必要があります。

マネージド ID

マネージド ID は、さまざまなソフトウェア コンポーネント間の通信を保護するために使用されるシークレット/資格情報の管理に関して開発者が直面した課題に対応して作成されました。
マネージド ID により、開発者が資格情報を手動で管理する必要がなくなります。
マネージド ID は、アプリケーションが Azure AD 認証をサポートする任意のリソースに接続するために使用できる ID です。

Azure リソースのマネージド ID とは

ざっくり覚える、Azureサービス プリンシパルとマネージド ID

Azure によって提供される認証ツールは2つある
１）サービス プリンシパル
２）マネージド ID
２つともの機能的にはだいたい同じ。
サービスプリンシパルは、初期設定や情報管理の運用がめんどいので、Azure内の認証ツールは基本、簡単発行・運用ができるマネージドID利用が推奨。
マネージドID は、「オンプレミスのアプリケーション または サービス」 は未サポートなので、オンプレミス利用時はサービスプリンシパルを使わざるえない

Azure PowerShell で自動化する時に使用する Identity について

システム割り当て

Azure の一部のサービスでは、そのサービス インスタンスでマネージド ID を直接有効にするオプションが提供されます。
有効にするとすぐにシステムによって割り当てられたマネージド ID の場合、別の ID が AAD で作成され、サービス インスタンスのライフ サイクルにリンクされます。
その特定の ID を使用して AAD からトークンを要求できるのは、その Azure リソースだけです。

マネージド ID の種類

VM

ロール割り当て

ユーザー割り当て

ユーザー割り当てマネージド ID は、それを使用するリソースとは別に管理されます。
この分離により、この ID を Azure サービスの複数のインスタンスに割り当てることができます。

マネージド ID の種類

VM

最小特権の原則

アクセス権を付与する場合は最小特権の原則に従う

例えば、
マネージド ID (ClientId = 1234) に StorageAccount7755 への読み取りおよび書き込みアクセス許可が付与され、LogicApp3388 に割り当てられている場合、
マネージド ID やストレージ アカウントに対する直接的な権限は持たないが、LogicApp3388 内でコードを実行する権限を持つ Alice は、そのマネージド ID を使用するコードを実行することで、StorageAccount7755 との間でデータの読み取りと書き込みを行うこともできます。

デバイス ID

デバイス ID とは

Windows 仮想マシン

Azure AD を使用して Azure の Windows 仮想マシンにログインする

VM ロールの割り当てを構成する

Azure AD 資格情報を使用して VM にログインするには、最初に VM のロールの割り当てを構成する必要があります。
VM にログインできるユーザーを決定する Azure RBAC ポリシーを構成する必要があります。
VM へのログインを承認するには、次の 2 つの Azure ロールが使用されます。
- 仮想マシンの管理者ログイン: このロールを割り当てられたユーザーは、管理者特権を持つユーザーとして Azure 仮想マシンにログインできます。
- 仮想マシンのユーザー ログイン: このロールが割り当てられたユーザーは 正規ユーザーの権限を持つユーザーとして Azure 仮想マシンにログインできます。

注意
仮想マシンの管理者ログインと仮想マシンのユーザー ログインのロールは、dataActions を使用しているため、管理グループのスコープで割り当てることはできません。 現時点では、これらのロールは、サブスクリプション、リソース グループまたはリソース スコープでのみ割り当てることができます。

Azure AD Domain Services

Azure Active Directory Domain Services とは

アプリケーション プロキシ

Azure AD アプリケーション プロキシとは、オンプレミスの Web アプリケーションにリモートからアクセスできるようにする Azure AD の機能です。
Azure portal で構成し、外部のパブリック URL を発行して内部のアプリケーション サーバーに接続します。
VPN やリバース プロキシに代わるもので、ローミング (リモート) ユーザー向けです

Azure AD アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する

Azure 管理グループ

Azure 管理グループとは

管理グループを使うと、サブスクリプションの種類に関係なく、大きな規模でエンタープライズ レベルの管理を行うことができる

【Azure】権限管理の仕組み

ルート管理グループ

各ディレクトリのルート管理グループ

各ディレクトリには、ルート管理グループと呼ばれる 1 つの最上位管理グループがある

Azure RBAC

Azure ロールベースのアクセス制御 (Azure RBAC) とは

Azure Active Directory のロールベースのアクセス制御の概要

RBAC（ロールベースアクセス制御）とは？Azureを安全に利用するための権限管理

ロールベース アクセス制御(RBAC) で役割分担

緑：Azure ADに対するロール
青：Azureリソースに対するロール ※[サブスク][リソースグループ][リソース]含む
赤：サブスクリプションのみに対するロール ※(旧)RBAC

※RBACの有効範囲は、青(赤含む)の範囲になります。

Azure ロール

Azure VM や Azure Storage などの、各種リソースへのアクセス権限を割り当てる

Azure ロールの定義について

Azure ロール

コンピューティングやストレージなどの Azure リソースに対するきめ細かなアクセス管理を提供する
Azure Resource Manager 上に構築された承認システム

Azure 組み込みロール

Azure ロール、Azure AD ロール、従来のサブスクリプション管理者ロール

ロール定義

ロール定義

ロール定義はアクセス許可のコレクションです。 単にロールと呼ばれることもあります。
ロール定義では、実行できるアクション (読み取り、書き込み、削除など) が一覧表示されます。
許可されるアクション、あるいは基となるデータに関連するアクションから除外されるアクションを一覧表示することもできます。

コントロールアクション

Actions
NotActions

NotActions

NotActions アクセス許可では、許可される Actions (ワイルドカード (*) を使用) から取り除く (除外する) コントロール プレーン アクションを指定

NotActions でアクションを除外するロールをユーザーに割り当てたうえで、同じアクションへのアクセス権を付与する 2 番目のロールを割り当てた場合、
ユーザーはそのアクションの実行が許可されます。
NotActions は拒否ルールとは異なり、特定のアクションを除外する必要があるときに、許可されるアクションのセットを作成するのに便利な方法にすぎません。

データアクション

データ アクションの例

Alice はサブスクリプション スコープで所有者ロールに割り当てられています。

Alice のサブスクリプション スコープにはワイルドカード (*) アクションがあるため、そのアクセス許可が継承され、すべてのコントロール プレーン アクションを実行できます。
Alice は、コンテナーの読み取り、書き込み、および削除を行うことができます。

しかし、Alice は追加の手順を行わずにデータ プレーン アクションを実行することはできません。
たとえば、既定では、Alice はコンテナー内の BLOB を読み取ることができません。
BLOB を読み取るには、Alice はストレージ アクセス キーを取得し、それを使用して BLOB にアクセスする必要があります。

DataActions

AssignableScopes

AssignableScopes

ロール定義を割り当てることができるスコープを指定します。
(ルート、管理グループ、サブスクリプション、またはリソース グループ)
カスタム ロールを必要とする管理グループ、サブスクリプション、またはリソース グループのみで、その割り当てを利用できるようにすることができます。
少なくとも 1 つの管理グループ、サブスクリプション、またはリソース グループを使用する必要があります。

所有者

所有者

Azure RBAC でロールを割り当てる権限を含め、すべてのリソースを管理するためのフル アクセスを付与
Actions
“*“
DataActions
”なし”

Contributor（共同作成者）

すべての種類の Azure リソースを作成および管理できる
他のユーザーにアクセス権を割り当てたり、削除したりすることはできない

Contributor

Reader（閲覧者）

User Access Administrator（ユーザーアクセス管理者）

リソースに対するユーザーアクセスを管理

組み込みロール

Azure 組み込みロール

Virtual Machine Contributor

Virtual Machine Contributor

仮想マシンの作成と管理、ディスクの管理、ソフトウェアのインストールと実行、VM 拡張機能を使用した仮想マシンのルート ユーザーのパスワードのリセット、VM 拡張機能を使用したローカル ユーザー アカウントの管理

Virtual Machine Administrator Login

Virtual Machine Administrator Login

ポータルで仮想マシンを表示し、管理者としてログインできる

Network Contributor

Network Contributor

ネットワークを管理できます。ただし、それらへのアクセスは含まれません。

セキュリティ管理者

セキュリティ管理者

Microsoft Defender for Cloud のアクセス許可を表示および更新します。
セキュリティ閲覧者と同じアクセス許可があり、セキュリティ ポリシーの更新、アラートと推奨事項の無視も可能になります。

Managed Identity Contributor

Managed Identity Contributor

ユーザー割り当て ID の作成、読み取り、更新、削除

カスタム ロール

Azure カスタム ロール

カスタム ロールは、ユーザー、グループ、サービス プリンシパルに対して、管理グループ (プレビューのみ)、サブスクリプション、およびリソース グループのスコープで割り当てることができます

カスタム ロールのプロパティ

Azure PowerShell を使用して Azure カスタム ロールを作成または更新する

Azure portal を使用して Azure カスタム ロールを作成または更新する

カスタム ロールの作成を開始するには、次の 3 つの方法
・ロールを複製
・最初から行う
・JSON から始める

カスタム ロールを割り当て可能にするサブスクリプションまたはリソース グループを開き、 [アクセス制御 (IAM)] を開きます。
[追加] をクリックし、 [カスタム ロールの追加] をクリックします。

ロールを複製する

１．Azure portal で、カスタム ロールを割り当て可能にするサブスクリプションまたはリソース グループを開き、 [アクセス制御 (IAM)] を開きます。
⒉．[ロール] タブをクリックして、すべての組み込みおよびカスタム ロールの一覧を表示
　　複製するロールを検索

リソース プロバイダー

Azure リソース プロバイダーと種類

Azure リソース プロバイダーは、Azure サービスの機能を提供する REST 操作のコレクション

Azure リソース プロバイダーの操作

Microsoft.Resources

Microsoft.Network

Azure サービス:Application Gateway、Azure Bastion、Azure DDoS Protection、Azure DNS、Azure ExpressRoute、Azure Firewall, Azure Front Door Service、Azure Private Link、Load Balancer、Network Watcher、Traffic Manager、Virtual Network、Virtual WAN、VPN Gateway

microsoft.web

Microsoft.Web/sites/start/Action Web アプリを起動

ロール割り当て

Azure ロールの割り当てについて

Azure ロールを割り当てる手順

手順 1:アクセスが必要なユーザーを決定する
手順 2:適切なロールを選択する
手順 3:必要なスコープを特定する
手順 4. 前提条件を確認する
手順 5. ロールを割り当てる

Azure RBACでAzureリソースへのアクセス権を管理する

※今回は仮想マシン共同作成者ロールをユーザーに付与
1. Azure Portalで、アクセス制御を設定するスコープを表示 (今回は仮想マシン)

  1. ブレードの [アクセス制御(IAM)] を選択し、[+追加] > [ロールの割り当ての追加] をクリック

  1. [役割] でロール定義、[アクセスの割り当て先] でロールを割り当てるセキュリティプリンシパルの種類、
    　[選択] でロールを割り当てる対象を選択し、[保存] をクリック

複数のロールの割り当て

Azure RBAC は加算方式のモデルであるため、自分で行ったロール割り当ての合計が自分の実際のアクセス許可になる

ユーザーにサブスクリプション スコープの共同作成者ロールとリソース グループの閲覧者ロールが付与されている例
共同作成者アクセス許可と閲覧者アクセス許可を足すと、実質的にサブスクリプションの共同作成者ロールになる

スコープ

Azure RBAC のスコープについて

“スコープ” は、アクセスが適用されるリソースのセット
4つのレベル (管理グループ、サブスクリプション、リソース グループ、リソース) でスコープを指定できます。

サブスクリプションの移転

Azure サブスクリプションを別の Azure AD ディレクトリに移転する

MOSP Azure サブスクリプションの課金所有権を別のアカウントに譲渡する

サブスクリプションを別の Azure AD テナント アカウントに譲渡する

サブスクリプションの課金所有権を別の Azure AD テナントのアカウントに譲渡する場合は、サブスクリプションを新しいアカウントのテナントに移動できる

アクセス権限昇格

Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる

Azure Policy

Azure Policy とは

Azure Policy を構成する

Azure Policyの基本のキ（定義の読み方）

リソースはこうあるべきだ／こうなってはいけない、を定義して監視します。

Azure Policyを爆速で理解する

Azure Policy を使用してリソースを制御および監査する

【AZ-900】Azure Policyとは？具体例を交えてわかりやすく解説！

Azure Policyは、Azureリソースを組織のルールに沿った状態に保つための仕組み
- ルールに沿ったリソースの作成を強制
- ルール違反のリソースがあればお知らせ（監査）

ポリシー定義

ポリシー定義

定義の場所

定義の場所

イニシアティブまたはポリシーを作成する際には、定義の場所を指定する必要があります。
定義の場所は、管理グループまたはサブスクリプションにする必要があります。
この場所によって、イニシアティブまたはポリシー定義を割り当てることができるスコープが決まります。
リソースは、割り当て対象とする定義の場所の ダイレクトメンバー か、その階層内の子である必要があります。

サブスクリプションの場合 - そのサブスクリプション内のリソースだけをポリシー定義に割り当てることができます。
管理グループの場合 - 子管理グループと子サブスクリプション内のリソースだけをポリシー定義に割り当てることができます。 ポリシー定義を複数のサブスクリプションに適用する予定がある場合、その場所は各サブスクリプションを含む管理グループである必要があります。

組み込みポリシー定義

Azure Virtual Machines 用の Azure Policy 組み込み定義

Microsoft Defender for CloudのAzure Policy組み込み定義

カスタム ポリシー定義

効果

Azure Policy の効果について

Azure Policy / Effect 効果を整理する (AuditIfNotExits / DeployIfNotExits)

Azure Policy が条件にマッチした際に、どのような行動を起こすのかを定義するのが effect です。

ポリシー効果ごとの評価タイミング
ポリシーの評価がいつ行われるかですが、基本的にはリソースのデプロイ時に評価されます1。

ここで、デプロイというのは、新規作成も変更もどちらも含みます。

このように、効果によって評価されるタイミングが異なります。

なかでもIfNotExistsの2つはピンとこないかもしれません。これのキモは、いま直接デプロイしているリソースではないリソースも含めた評価をしたいときに使えることです。

Deny

Deny

Deny は、ポリシーを通して定義された基準に一致していないために失敗するリソース要求を防ぐために使用されます

Audit

Audit

非準拠のリソースが評価された場合、Audit を使用してアクティビティ ログに警告イベントが作成されますが、要求は停止されません

DeployIfNotExists

DeployIfNotExists

DeployIfNotExists ポリシー定義は条件が満たされたときにテンプレートのデプロイを実行します。
DeployIfNotExists として設定された有効なポリシー割り当てには、修復を行うための マネージド ID が必要

DeployIfNotExists は、リソース プロバイダーによって、サブスクリプションまたはリソースの作成または更新要求が処理され、成功を示す状態コードが返されてから、
構成可能な遅延後に実行されます。
関連するリソースがない場合、または ExistenceCondition によって定義されたリソースが true と評価されない場合、テンプレートのデプロイが発生します。
デプロイの時間は、テンプレートに含まれるリソースの複雑さによって異なります。

イニシアティブ

Azure Policy イニシアチブ定義の構造

イニシアティブを使用すると、複数の関連するポリシー定義をグループ化できます。
グループを単一の項目として操作するので、割り当てと管理が単純になります。
それぞれのポリシーを個別に割り当てるのではなく、イニシアティブを適用することになります。

Azure Policy のイニシアティブとは

Azure Policy のイニシアティブは、関連するポリシーをまとめてグループ化する手段です。
イニシアティブ定義には、大きな目標に対するコンプライアンスの状態を追跡するのに役立つすべてのポリシー定義が含まれます。

スコープ

Azure Policy でのスコープについて

“スコープ” という用語は、ポリシー定義が割り当てられる、すべてのリソース、リソース グループ、サブスクリプション、または管理グループのことを指します。

ポリシー割り当て

チュートリアル:コンプライアンスを強制するポリシーの作成と管理

【AZ-900】Azure Policyとは？具体例を交えてわかりやすく解説！

割り当て済みの定義は「割り当て」のメニューから確認できます

コンプライアンス

Azure リソースのコンプライアンス データを取得する

コンプライアンスのしくみ

イニシアティブまたはポリシー定義が割り当てられ、評価されると、ポリシー ルールの条件とそれらの要件に対するリソースの準拠に基づいて、結果のコンプライアンス状態が決定される

【AZ-900】Azure Policyとは？具体例を交えてわかりやすく解説！

Azure Policyのルールが守られているかどうか（準拠状況）は「概要」や「コンプライアンス」のメニューから確認できます。

修復

Azure Policy を使って準拠していないリソースを修復する

deployIfNotExists や modify の効果を含むポリシーに準拠していないリソースは､修復 を使って準拠状態にすることができる

マネージド ID

修復のアクセス制御の仕組み

deployIfNotExists ポリシーの評価時に Azure Policy によりテンプレートのデプロイが開始される場合、
またはmodify ポリシーの評価時にリソースが変更される場合には、
これらの操作にはポリシーの割り当てに関連付けられているマネージド ID が使用されます。
ポリシーの割り当てでは、Azure リソースの承認にマネージド ID が使用されます。

Azure Blueprint

Azure Blueprint とは

ブループリントは、さまざまな リソーステンプレート やその他のアーティファクトのデプロイを宣言によって調整する手法
- ロールの割り当て
- ポリシーの割り当て
- Azure Resource Manager テンプレート (ARM テンプレート)
- リソース グループ

PowerShell を使用した Azure Blueprints の管理

Azure Blueprints は、Azure ガバナンスのための「ワンストップショップ」を提供します。
JSON テンプレートとコントロールされた統合ワークフローを実装することによって、標準化された Azure 環境を定義、デプロイ、実施、および維持できます。

ポータル内でブループリントを定義して割り当てる

ブループリント定義

ブループリント定義

ブループリント定義の場所

ブループリント定義の場所

ブループリント定義を作成するとき、ブループリントの保存場所を定義します。
ブループリントは、自分が共同作成者のアクセス権を持っている管理グループまたはサブスクリプションに保存できます。
保存場所が管理グループである場合、その管理グループのすべての子サブスクリプションへの割り当てにブループリントを使用できます。

ブループリント割り当て

ブループリント割り当て

リソース ロック

Azure Blueprint でのリソース ロックについて

チュートリアル:Azure Blueprints のリソース ロックを使用して新しいリソースを保護する

ロック モード

ロック モードと状態

ブループリント割り当てに適用されるロック モードには、次に示す 3 つのオプションがあります。
ロックしない、読み取り専用、削除しない。

ロックしない

読み取り専用

編集/削除できません
リソース グループは読み取り専用であり、リソース グループ上のタグを変更することはできません。 このリソース グループに対しては、ロックなしリソースの追加、移動、変更、削除を行うことができます。
読み取り専用
いかなる方法でもリソースを変更することはできません。 変更することも削除することもできません。

削除しない

ロック 状態

ロック モードと状態

ブループリント割り当て内のアーティファクトによって作成されたリソースは、次の 4 つのいずれかの状態になります。ロックなし、読み取り専用、編集/削除できません、または削除不可。 各種のアーティファクトは、ロックなしの状態にすることができます。

ロックなし

編集/削除できません

リソース グループは読み取り専用であり、リソース グループ上のタグを変更することはできません。 このリソース グループに対しては、ロックなしリソースの追加、移動、変更、削除を行うことができます。

読み取り専用

削除不可

Azure Monitor

https://az-start.com/azure-monitor-overview/

Azure Monitor エージェント

Azure Monitor エージェントの概要

すべての新しい仮想マシン、スケール セット、オンプレミス サーバーに Azure Monitor エージェントをデプロイして、サポートされているサービスと機能のデータを収集します

Azure Monitor のエージェント用の Resource Manager テンプレートのサンプル

Log Analytics エージェント

Azure の Windows 仮想マシンおよび Linux 仮想マシンにレガシ Log Analytics エージェントをインストールして、Log Analytics ワークスペースにそれを接続

Log Analytics エージェント

Microsoft Sentinel のデプロイで Log Analytics エージェントを使用している場合は、AMA への移行の計画を開始することをお勧めします

Log Analytics エージェントの概要

Azure Monitor のエージェント用の Resource Manager テンプレートのサンプル

Log Analytics エージェント

Azure の Windows 仮想マシンおよび Linux 仮想マシンにレガシ Log Analytics エージェントをインストールして、Log Analytics ワークスペースにそれを接続
これは、Azure Log Analytics 仮想マシン拡張機能を有効にすることで実現される

Log Analytics エージェント仮想マシン拡張機能

https://learn.microsoft.com/ja-jp/azure/virtual-machines/extensions/oms-windows

Azure Monitor ログでは、クラウドとオンプレミスの資産全体にわたって監視機能を提供します。
Windows 用の Log Analytics エージェント仮想マシン拡張機能は、Microsoft によって発行およびサポートされています。
この拡張機能では、Azure 仮想マシンに Log Analytics エージェントがインストールされ、仮想マシンが既存の Log Analytics ワークスペースに登録されます。

この拡張機能では、ターゲット Log Analytics ワークスペースのワークスペース ID とワークスペース キーが必要です。

Log Analytics ワークスペース

Log Analytics ワークスペースは、Azure Monitor、Microsoft Sentinel や Microsoft Defender for Cloud などの他の Azure サービスからの ログデータ用の固有の環境です。
各ワークスペースには、複数のデータ行を含む別々の列に編成された複数のテーブルが含まれています。
テーブル内の各データは、指定された期間保持され、その後は削除されるか、より少ない保持料金でアーカイブされます。

Log Analytics ワークスペースの概要

Log Analytics ワークスペースは、
Azure Monitor、および Microsoft Sentinel や Microsoft Defender for Cloud などの他の Azure サービスからのログ データのための固有の環境です。

Log Analytics ワークスペースを作成する

ログとデータを収集すると、情報はワークスペースに保存されます。
#ワークスペースには、一意のワークスペース ID とリソース ID があります。
#ワークスペース名は、指定したリソース グループ内で一意である必要があります。
ワークスペースを作成したら、データ ソースとソリューションのデータをそこに保存するように構成します。

ログ クエリ

Azure Monitor でのログ クエリ

Azure Monitor ログは Azure Data Explorer を基盤としており、ログ クエリは同じ Kusto 照会言語 (KQL) を使って作成します。

テーブル

Log Analytics ワークスペースのテーブルを管理する

リソースの種類別に整理された Azure Monitor ログ テーブルリファレンス

AzureDiagnostics

Azure Diagnostics モードを使用する Azure サービスのリソース ログが格納されます

CommonSecurityLog

共通イベント形式のイベントを収集するためのもの

SecurityEvent

Azure Security Center または Azure Sentinel によって Windows マシンから収集されるセキュリティ イベント

SecurityAlert

セキュリティ製品によって生成されたアラート

Azure ポータルから Log Analytics ワークスペースの テーブルごとに 保管期間・Basic/Archive を設定する

コンピューター グループ

Azure Monitor ログ クエリでのコンピューター グループ

コンピューター グループを使用して、ログ クエリの範囲を特定のコンピューターのセットに限定することができる

アラート

Azure Monitor アラートとは、 Azure Monitor で監視しているインフラストラクチャ・アプリケーション内のデータの状態をユーザーに通知する機能のことです。
Azure Monitor のデータプラットフォームでは、任意のメトリック・ログデータに対してアラートを生成できます。

Azure Monitor アラートとは

Azure Monitorアラートとは？特徴や利用するメリットを解説

アクション グループ

アクション グループとは、どの宛先の電子メールに送信するか、どの function を呼び出す、などの通知方法を定義したもの

Azure Monitor のアクション グループ

Azure Monitor アクション グループを使用すると 、アラートがトリガーされたときに実行するアクション の一覧を定義できます

Azure Portal でのアクション グループの作成および管理

Azure Monitor のデータによって、インフラストラクチャまたはアプリケーションに問題がある可能性があることが示されると、アラートがトリガーされます。 Azure Monitor、Azure Service Health、Azure Advisor は、アクション グループ を使用して、アラートについてユーザーに通知し、アクションを実行します。
アクション グループは、Azure サブスクリプションの所有者によって定義された通知設定のコレクションです。

[Azure Monitor] アクション グループについて

アラート インスタンス

アラート インスタンスを管理する

アラート ルール

新しいアラート ルールを作成する

ディメンション

Azure Monitorのアラートルールを作成する際、ディメンションで分割することができます。
これにより、複数のAzureリソースで同じ条件を監視するために、数値または文字列の列の組み合わせをグループ化することによってアラートが個別のアラートに分割されます1。
また、1つのメトリックアラートルールで、メトリックの複数の次元値を監視することもできます。
メトリックのディメンションとは、メトリックの値を記述するためにより多くのデータを保持する名前と値のペアです

ディメンションを使用してターゲットを絞り込む

メトリック アラート

メトリック アラート

リソース メトリックの条件を定期的に評価することで、リソースを監視

ログ アラート

ログ アラート

アクティビティ ログ アラート

アクティビティ ログ アラート

アラート処理ルール

アラート処理ルール

Azure Monitorのアラート処理ルールを使って非監視設定(アラート抑止)

アラート処理ルールはスコープ(リソース)を指定して設定する
　アラート処理は適用するスコープ(リソース）を指定して設定します。
　例えば特定の仮想マシンやリソースグループに対しての適用になります。
　アラートルールではなくリソース指定での指定になります。

アラート処理ルールで出来る事は2つ
　アラート処理ルールで出来る事は2つになります。
- 抑制
アラートの発動を停止する
- アクション グループの適用
特定のスコープに対してアクショングループを適用する

プラットフォーム ログ

Azure プラットフォーム ログの概要

アクティビティ ログ

サブスクリプションにあるAzureリソースに対して行われた書き込み操作（作成・変更・削除）を記録したログ

Azure Monitor アクティビティ ログ

カテゴリ

Categories

アクティビティ ログの各イベントには、特定のカテゴリがある

管理カテゴリ

管理カテゴリ

このカテゴリには、Resource Manager で実行されるすべての作成、更新、削除、アクション操作のレコードが含まれています。
このカテゴリで表示されるイベントの種類として、“仮想マシンの作成”、“ネットワーク セキュリティ グループの削除” などがあります。

セキュリティ カテゴリ

セキュリティ カテゴリ

Microsoft Defender for Cloud によって生成されたアラートのレコードが含まれます。
セキュリティ イベントの例としては、“Suspicious double extension file executed” (疑わしい二重拡張子ファイルが実行されました) があります。

リソース ログ

Azure リソース内 (データ プレーン) で実行された操作の分析情報を提供します。 たとえば、キー コンテナーからのシークレットの取得や、データベースへの要求などです。 リソース ログの内容は、Azure サービスとリソースの種類によって異なります。

Azure リソース ログ

Azure Active Directory (Azure AD) ログ

サインイン アクティビティの履歴と、特定のテナントに対して Azure AD で行われた変更の監査証跡が含まれます。

VM insights

VM insights の有効化の概要

Application Insights

インストルメント化されたアプリケーション コードからデータを収集し、アプリケーションのアクティビティ、パフォーマンス、カスタム メトリック、および例外を追跡する、テレメトリ フレームワーク

Application Insights の概要

Application Insights について

テレメトリ

ソフトウェアやアプリケーションがパフォーマンス改善や品質向上を目的として収集するユーザーの利用状況データのこと

Application Insights Telemetry のデータ モデル

Application Insights は、アプリケーションのパフォーマンスと使用状況を分析できるように、Web アプリケーションから Azure portal にテレメトリを送信します。
テレメトリ モデルを標準化して、プラットフォームと言語に依存しない監視を作成できます。

リクエスト

例外

依存関係

トレース

イベント

メトリック

Microsoft Defender for Cloud

Microsoft Defender for Servers を有効にすると、次の機能が自動的に利用可能になります。
- サポートされているバージョンの Windows および Linux の脅威検出
- ファイルの整合性の監視
- ジャストインタイムの VM アクセス
- Qualys または Threat and Vulnerability Management (TVM) のいずれかを展開するオプションを備えた統合された脆弱性評価
- 適応型アプリケーション制御
- 適応型ネットワークの強化
- ネットワーク マップ
- 規制順守ダッシュボード

Microsoft Defender for Cloud とは

Microsoft Defender for Cloud は、リソースのセキュリティを可視化して制御することで、脅威の防止、検出、対応を行うのに役立ちます。
これにより、サブスクリプション全体に統合セキュリティの監視とポリシーの管理を提供し、気付かない可能性がある脅威を検出し、セキュリティ ソリューションの広範なエコシステムと連動

Microsoft Defender for Cloud とは

Azure、オンプレミス、マルチクラウド (Amazon AWS および Google GCP) のすべてのリソースに対するクラウド セキュリティ態勢管理 (CSPM) と クラウド ワークロード保護プラットフォーム (CWPP)

Microsoft Defender for Cloud によって監視される Azure リソースは何ですか?

Microsoft Defender for Cloudとは？～概要、メリット、コストを解説～

2021年に「Azure Security Center」と「Azure Defender」が名称を変更して「Microsoft Defender for Cloud」となりました。

[Azure] Security Center の 8 つの機能について数行にまとめてみた

セキュリティ ポリシー

Azure セキュリティ ポリシーは、Azureのリソースに対してのポリシーを定義し、各リソースがセキュリティ要件に準拠するようにするためのもの
Azure Policy で作成される Azure ポリシー定義は、制御する特定のセキュリティ条件に関するルール
Defender for cloud は、主に、特定の条件と構成を確認し、コンプライアンスを報告する “監査” ポリシーを使用
セキュリティ設定を適用するために使用できる “強制” ポリシーもある

セキュリティ ポリシーとは何ですか。

Azure Policy組み込み定義

Microsoft Defender for CloudのAzure Policy組み込み定義

イニシアチブグループには、「Defender for Cloud」 カテゴリに Azure Policy イニシアチブ定義の一覧が表示されます
既定のイニシアティブ グループには、Defender for Cloud の既定のイニシアティブである Microsoft クラウド セキュリティ ベンチマークに含まれるすべての Azure Policy 定義の一覧が示されています
カテゴリグループには、「Defender for Cloud」カテゴリにすべてのAzure Policy定義の一覧が表示されます

セキュリティ イニシアチブ

セキュリティ イニシアチブとは

セキュリティ イニシアチブは、特定の目標や目的を実現するためにグループ化された Azure Policy の定義またはルールのコレクション
セキュリティ イニシアチブは、一連のポリシーを論理的にグループ化して単一の項目として扱うことで、ポリシーの管理を簡略化

カスタム イニシアチブ

カスタム Azure セキュリティ イニシアチブとポリシーを作成する

カスタム イニシアチブは、セキュリティで保護されたスコアには含まれていませんが、作成したポリシーに環境が従っていない場合は、レコメンデーションを受け取ります。
作成したカスタム イニシアチブはすべてのレコメンデーションの一覧に表示されます。イニシアチブごとにフィルター処理して、イニシアチブに関する推奨事項を確認することができます。

イニシアティブをサブスクリプションに追加するには

規制コンプライアンス ダッシュボード

チュートリアル:規制に対するコンプライアンスの向上

目指せ！トップガン - クラウドセキュリティ 3回目：CISOの質問にタイムリーに応えるための10の方法（前編）

適応型アプリケーション制御

どのアプリケーションを仮想マシン上で実行できるようにするかを制御することができるインテリジェントで自動化されたソリューション
適応型アプリケーション制御は、既知の安全なアプリケーションの許可リストを定義し、不正なアプリケーションの実行を防止する
適応型アプリケーション制御を有効にして構成した場合、安全なものとして定義したもの以外のアプリケーションが実行されると、セキュリティ アラートが表示される

適応型アプリケーション制御を使用して、マシンの攻撃対象領域を減らす

適応型アプリケーション制御とは、マシンに対して既知の安全なアプリケーションの許可リストを定義するためのインテリジェントで自動化されたソリューションです。

サポートされているマシン:
Windows および Linux が実行されている Azure および Azure 以外のマシン
Azure Arc マシン

データ収集

Defender for Cloud は、セキュリティの脆弱性と脅威を監視するために、
Azure 仮想マシン (VM)、仮想マシンスケールセット、IaaS コンテナー、非 Azure (オンプレミスを含む) マシンからデータを収集します。
一部の Defender プランでは、ワークロードからデータを収集するために監視コンポーネントが必要になります。

不足している更新プログラム、OS のセキュリティ設定ミス、エンドポイント保護のステータス、正常性と脅威の防止を可視化するためには、データ収集が欠かせません。
データ収集を必要とするのは、コンピューティング リソース (VM、仮想マシン スケール セット、IaaS コンテナー、非 Azure コンピューターなど) だけです。

Defender for Cloud によるデータの収集方法

データは以下を使用して収集されます。
- Azure Monitor エージェント (AMA)
- Microsoft Defender for Endpoint (MDE)
- Log Analytics エージェント
- Kubernetes 用の Azure Policy アドオンなどのセキュリティ コンポーネント

Azure Monitor エージェント

Microsoft Defender for Cloud を使用してサーバーを保護するために Azure Monitor エージェントをデプロイする

自動的に Azure Monitor エージェントをサーバーにデプロイできます。

ラボ 14: Microsoft Defender for Cloud

Microsoft Defender for Cloud によって監視される Azure リソースは何ですか?

仮想マシン (VM) ( Cloud Servicesを含む)
Virtual Machine Scale Sets
製品概要に記載されているさまざまな Azure PaaS サービス

Log Analytics エージェント インストールの自動プロビジョニングでは、何をもって VM を適格と見なしますか?

Windows または Linux IaaS VM は、次の条件で適格とします。
- 現在、Log Analytics エージェント拡張機能が VM にインストールされていない。
- VM が実行状態である。
- Windows または Linux Azure 仮想マシン エージェントがインストールされている。
- VM は、Web アプリケーション ファイアウォールや次世代ファイアウォールなどのアプライアンスとしては使用されません。

セキュリティ アラート

セキュリティのアラートとインシデント

Microsoft Defender for Cloud データを継続的にエクスポートする

Microsoft Defender for Cloud では、詳細なセキュリティ アラートと推奨事項が生成されます。
これらのアラートと推奨事項の情報を分析するために、
それらを Azure Log Analytics、Event Hubs、または別の SIEM、SOAR、または IT サービス管理ソリューションにエクスポートできます。

SQL Database と Azure Synapse Analytics のアラート

A possible vulnerability to SQL Injection (SQL インジェクションにつながる可能性のある脆弱性)
アプリケーションにより、データベースでエラーのある SQL ステートメントが生成されました。 これは、SQL インジェクション攻撃に対する脆弱性があることを示している可能性があります。
エラーのあるステートメントの理由としては、次の 2 つが考えられます。
アプリケーション コードの欠陥により、エラーのある SQL ステートメントが作成された可能性がある。 または、アプリケーション コードまたはストアド プロシージャでユーザー入力がサニタイズされず、エラーのある SQL ステートメントが作成され、SQL インジェクションに悪用される可能性がある。

Potential SQL injection(SQL インジェクションの可能性)
SQL インジェクションに脆弱な特定されたアプリケーションに対してアクティブな悪用が発生しました。
これは、攻撃者が脆弱なアプリケーション コードまたはストアド プロシージャを使用して、悪意のある SQL ステートメントを挿入しようとしていることを意味します。

クイックスタート: セキュリティ アラートの電子メール通知を構成する

アラート疲れを防ぐために、Defender for Cloud は送信メールの量を制限します。 各サブスクリプションについて、Defender から次のようにメールが送信されます。
- 重要度が高いアラートに関しては、1 日あたり約 4 通のメール
- 重要度が中程度のアラートに関しては、1 日あたり約 2 通のメール
- 重要度が低いアラートに関しては、1 日あたり約 1 通のメール

Microsoft Defender for Cloud から外部へのアラート通知方法について

デメリット
通知が抑制されており、通知間隔やメール通知量が制限されています。
重要度が高いアラートでも、6時間間隔、1通のみです。

ワークフローの自動化

ワークフローの自動化を使用して応答を自動化する

ワークフローの自動化とは、グループ化された手順の集合であり、セキュリティ対応チームは、1 回のクリックで実行できます。 これらの手順は、特定のアラートが検出された場合に、Defender for Cloud で実行されます。 これらのアクションは、自動的にはトリガーされ “ません”。ユーザーが操作して実行する必要があります。

ワークフローの自動化は、Azure Logic Apps を基に構築されています。

クラウドトリガーに対する Microsoft Defender への応答を自動化する

Microsoft Defender for Servers

Defender for Servers のデプロイを計画する

Just-In-Time (JIT) アクセス

Just-In-Time (JIT) VM アクセスについて

JIT を構成して使用するために必要なアクセス許可は何ですか?

Just-In-Time アクセスを使用して管理ポートをセキュリティで保護する

サポート対象外 - 次の理由で JIT をサポートしていない VM。
- ネットワーク セキュリティ グループ (NSG) または Azure ファイアウォールが見つからない - JIT では、NSG が構成されていることか、ファイアウォール構成 (またはその両方) が必要です
- クラシック VM - Azure Resource Manager を使用してデプロイされた VM は JIT でサポートされます。
- その他 - サブスクリプションまたはリソース グループのセキュリティ ポリシーで JIT ソリューションが無効になっている場合です。

Microsoft Defender for Cloud から VM で JIT を有効にする

Azure 仮想マシンの接続ページから JIT が有効な VM へのアクセス権を要求する

[接続] ページを開き、[アクセス権の要求] を選択

Qualys 脆弱性評価スキャナー

Azure およびハイブリッド マシンに対する Defender for Cloudの統合された Qualys 脆弱性評価スキャナー

Microsoft Defender for Storage

Microsoft Defender for Storage の概要

Microsoft Defender for Storage を有効にする

保護されるストレージの種類:
Blob Storage (Standard/Premium StorageV2、ブロック BLOB アカウント)
Azure Files (REST API および SMB 経由)
Azure Data Lake Storage Gen2 (階層型名前空間 (HNS) が有効になっている Standard/Premium アカウント)

Microsoft Defender for Containers

Microsoft Defender for Containers の概要

Microsoft Defender for Azure SQL

Microsoft Defender for Azure SQL の概要

データベースの潜在的な脆弱性を検出して軽減するのに役立ち、データベースに対する脅威を示す可能性のある異常なアクティビティに対するアラートを提供します。
- 脆弱性評価: データベースをスキャンして、脆弱性を検出、追跡、修復します。 脆弱性評価の詳細を確認してください。
- 脅威に対する保護: SQL Advanced Threat Protection に基づいて、詳細なセキュリティ アラートと推奨されるアクションを受け取り、脅威を軽減します。

脆弱性評価

SQL 脆弱性評価は、データベースの脆弱性を特定するのに役立ちます

ハイブリッド・マルチクラウド環境

クイックスタート: Azure 以外のマシンを Microsoft Defender for Cloud に接続する

Azure Arc 対応サーバー

Azure Connected Machine エージェント

Azure Connected Machine エージェントの概要

Azure Connected Machine エージェントは、Azure Arc によってサポートされるサーバーにインストールするパッケージです。
このエージェントは、Azure への接続と接続されたマシンの Azure ID を管理します。
TCP ポート 443 を介して Azure Arc へのアウトバウンド通信を安全に行います。

クイックスタート: Azure Arc 対応サーバーにハイブリッド マシンを接続する

エンドポイント保護

Microsoft Defender for Cloud での Endpoint Protection に関する評価と推奨事項

Microsoft Sentinel

オンプレからクラウドまで幅広く監視を行うことができるオールインワンな監視サービス
Microsoft Sentinel は、クラウドネイティブ型のスケーラブルなセキュリティ情報イベント管理（SIEM）および セキュリティ オーケストレーション（SOAR）ソリューション

Microsoft Sentinel とは

Microsoft Sentinel は、インテリジェントなセキュリティ分析と脅威インテリジェンスを企業全体に提供します。
Microsoft Sentinel を使用すると、攻撃の検出、脅威の可視化、予防的ハンティング、脅威への対応のための単一ソリューションが得られます。

分析ルールを使用してアラートをインシデントに関連付ける

Azure Sentinel でログ収集・分析基盤を構築してみた① ~Windows セキュリティイベントの収集~

Azure Sentinelの機能の紹介

ラボ 15: Microsoft Sentinel

Microsoft Sentinel とは？導入でできる4つの機能や導入メリットを解説

データ コネクタ

Microsoft Sentinel データ コネクタ

ワークスペースに Microsoft Azure Sentinel をオンボードしたら、データ コネクタを使用して Microsoft Sentinel へのデータの取り込みを開始できます。

Microsoft Azure Sentinel データ コネクタを見つける

Azure Active Directory Identity Protection

Log Analytics テーブル SecurityAlert

Azure Firewall

データ インジェスト方法 Azure サービス間の統合:診断設定ベースの接続
Log Analytics テーブル AzureDiagnostics

Windows ファイアウォール

Azure サービス間の統合:
Log Analytics エージェントベースの接続 (レガシ)

Azure Sentinelの初期設定

ログ フォワーダー

ログ フォワーダーをデプロイして Syslog および CEF ログを Microsoft Sentinel に取り込む

Syslog と CEF ログを Microsoft Sentinel に取り込むには (特に Log Analytics エージェントを直接インストールできないデバイスとアプライアンスから)、
デバイスからログを収集して Microsoft Sentinel ワークスペースに転送する Linux マシンを指定して構成する必要があります

デバイスまたはアプライアンスの CEF 形式のログを Microsoft Sentinel に取得する

脅威検知

カスタム分析規則

脅威を検出するためのカスタム分析規則を作成する

Azure Sentinel の分析ルールを使った脅威の検出

分析ルールとは、
集められたログの中から不審なものはどれかという定義を行い、脅威の検出を行うものです。
Azure Sentinel には多数の分析ルールのテンプレートが用意されており、それらによって脅威を検出し、攻撃から守ることができます。
分析ルールを見るには、Azure Sentinel の分析ブレードを開きます。

Azure Sentinel でログ収集・分析基盤を構築してみた② クエリによる脅威検知

[規則のテンプレート] をクリックし、[ルールの種類]から「Scheduled」を選択します。
[データソース]をクリックし、 「セキュリティイベント」を選択します。

アラート

Microsoft Sentinel でアラートに含まれるカスタム イベントの詳細を表示する

スケジュールされたクエリ分析ルールを使用すると、Microsoft Sentinel に接続されたデータ ソースのイベントを分析し、それらのイベントの内容がセキュリティの観点から重要な場合にアラートを生成できます。
これらのアラートは、Microsoft Sentinel のさまざまなエンジンを使用してさらに分析、グループ化、フィルター処理が行われ、SOC アナリストにとって注意が必要なインシデントへと抽出されます。

インシデント

Sentinel におけるインシデントとは「関連するアラートをまとめたグループ」

Microsoft セキュリティ アラートからインシデントを自動的に作成する

脅威ハンティング

セキュリティツールなどを活用し、組織のシステムやネットワークなどを探索し、悪意のある活動や脅威の兆候を発見し対処するプロセス
アラートなどを通じて受動的に脅威を検知する「脅威検知」に対して、脅威インテリジェンスやアノマリ、IoCを元に隠れた兆候を見つけ出す点が強調されています。

ハンティング ブックマーク

Microsoft Sentinel によるハンティング中にデータを追跡する

Microsoft Sentinel - Logs で実行したクエリが、関連すると思われるクエリ結果と共に保持される

SOAR

Microsoft Sentinel でのセキュリティ オーケストレーション、オートメーション、応答 (SOAR)

オートメーション ルール

自動化ルールを使って Microsoft Sentinel の脅威への対応を自動化する

プレイブック

Microsoft Sentinel のプレイブックを使用して脅威への対応を自動化する

プレイブックは、脅威への対応を自動化および調整する

チュートリアル: Microsoft Sentinel でオートメーション ルールとプレイブックを使用する

Azure Logic Apps

Azure Logic Apps の基本概念

Microsoft Sentinel のプレイブックは、エンタープライズ全体のシステムでタスクとワークフローをスケジュール、自動化、調整するのに役立つクラウド サービスである Azure Logic Apps で作成されたワークフローに基づいています

Microsoft Sentinel トリガー

Microsoft Sentinel トリガーの概要

Microsoft Sentinel インシデント (プレビュー)
ほとんどのインシデント自動化シナリオに推奨されます。
プレイブックは、エンティティやアラートを含むインシデント オブジェクトを受け取ります。
このトリガーを使用すると、プレイブックをオートメーション ルールにアタッチできるため、Microsoft Sentinel でインシデントが作成されたときにそれをトリガーでき、そのインシデントにオートメーション ルールのベネフィットのすべてを適用できます。

Microsoft Sentinel アラート (プレビュー)
アラートに対して Microsoft Sentinel ポータルから手動で実行する必要のあるプレイブック、またはアラートに対してインシデントを生成しないスケジュールされた分析ルールに推奨されます。

Microsoft Sentinel エンティティ (プレビュー)
調査または脅威ハンティングのコンテキストで、特定のエンティティに対して手動で実行する必要があるプレイブックに使用します。

Kusto 照会言語

Microsoft Sentinel の Kusto 照会言語

SC-200: Kusto クエリ言語 (KQL) を使用して Microsoft Sentinel のクエリを作成する

Azure Key Vault

Key Vaultは、Azureの主要な管理ソリューションの一つで、シークレットやキーなどの機密情報を安全に格納し、アクセスを制御できます。
シークレットとキーの違いは、シークレットは文字列として扱われる汎用的なデータ（例えばパスワードや接続文字列）であり、
キーは暗号化や署名などの暗号操作に使用される非対称鍵ペアです。
証明書もKey Vaultに格納できますが、証明書が作成されると同じ名前でキーとシークレットも作成されます。

Azure Key Vault の探索

「Azure Key Vault」を使ってセキュアなアプリを作ろう

Azure Key Vaultとは？クラウドへの安全なアクセスを実現するセキュリティサービス

キーコンテナ

Azure Key Vault を作成する

キー

Azure Key Vault により、データの暗号化に使用される暗号化キーの作成と制御が簡単になります。

キーについて

シークレット

パスワードやデータベース接続文字列などの汎用シークレットのセキュリティで保護されたストレージ
開発者から見ると、Key Vault API はシークレット値を文字列として受け取って返される
Key Vault 内のシークレットはすべて、暗号化した状態で格納される

シークレット

シークレットの属性

Key Vault マネージド ストレージ アカウント キー (レガシ)

Key Vault と Azure PowerShell を使用したストレージ アカウント キーの管理 (レガシ)

キーの再生成を有効にする

Key Vault でストレージ アカウント キーを定期的に再生成する場合は、
Azure PowerShell の Add-AzKeyVaultManagedStorageAccount コマンドレットを使用して、
再生成期間を設定できます。

証明書

アクセス モデル

アクセス モデルの概要

Azure Key Vault の実装例とアクセス制御

アクセスモデルとして重要なのは下記の２点です。
・ 管理プレーンとデータプレーンの２層に分かれている
・ アクセスマネージメントは、Azure AD の Security Principal をベースに行われる

どちらのプレーンでも、認証にはAzure ADが使われます。
管理プレーン： コンテナーの作成と削除、アクセス ポリシーなど、Key Vault そのものを管理
データ プレーン ：アクセス ポリシーに基づいて、どのプリンシパルが、キー コンテナーに格納されているデータを操作できるかを管理

管理プレーンにアクセス権がないと、コンテナの操作はできない
データプレーンにアクセス権がないと（アクセス ポリシーで許可されていないと）データにはアクセスできない

データプレーンのアクセスポリシーの変更は、管理プレーンの権限で、
アクセスポリシーの変更権とデータへのアクセス権とが別れているところが味噌になっています。

RBAC アクセス許可モデル

Azure のロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する

Key Vault データ プレーン操作のための Azure の組み込みロール

Azure portal にサインインします。
[リソース グループ] を選択し、キー コンテナーが含まれるリソース グループを選択します。
[アクセス制御 (IAM)] を選択します。
[ロールの割り当ての追加] を選択します。
[ロール] で、キー コンテナーに関連するロールを選択します。例えば、Key Vault Secrets Officer や [Key Vault Keys Operator] などです。
[割り当て先] で、キー コンテナーを選択します。
[メンバーの選択] で、アクセス許可を付与するユーザーやグループを検索して選択します。
[保存] を選択して、ロールの割り当てを完了します。

Key Vault Administrator

Key Vault Administrator

キー コンテナーとその内部にあるすべてのオブジェクト (証明書、キー、シークレットを含む) に対して、すべてのデータ プレーン操作を実行
キー コンテナー リソースの管理やロール割り当ての管理はできない

Key Vault Contributor

Key Vault Contributor

キー コンテナーを管理キー コンテナーを管理できる
Azure RBAC でのロール割り当ては許可されない
シークレット、キー、証明書へのアクセスも許可されない

Key Vault Crypto Officer

Key Vault Crypto Officer

キーコンテナーのキーに対して、アクセス許可の管理を除く任意の操作を実行

Key Vault Crypto User

Key Vault Crypto User

キーを使用した暗号化操作を実行

Key Vault Crypto Service Encryption User

Key Vault Crypto Service Encryption User

キーのメタデータを読み取り、wrap および unwrap 操作を実行

Key Vault Reader

Key Vault Reader

キー コンテナーとその証明書、キー、シークレットのメタデータを読み取ります。 シークレット コンテンツやキー マテリアルなどの機密値を読み取ることはできません。

Key Vault Secrets Officer

Key Vault Secrets Officer

キーコンテナーのシークレットに対して、アクセス許可の管理を除く任意の操作を実行

Key Vault アクセス ポリシー

Key Vault アクセス ポリシーを割り当てる

Key Vault アクセス ポリシーは、
特定のセキュリティ プリンシパル (ユーザー、アプリケーション、またはユーザー グループ) が、
Key Vault の シークレット、キー、証明書に対して、
さまざまな操作を実行できるかどうかを決定します

認証

Azure Key Vault の認証

Azure Key Vault に対する認証

Key Vault による認証は、特定のセキュリティ プリンシパルの ID を認証する役割を担当する Azure Active Directory と連携して機能します。
アプリケーションの場合、サービス プリンシパルを取得するには次の 2 つの方法があります。
- アプリケーションに対して、システムに割り当てられたマネージド ID を有効にする。
- マネージド ID を使用できない場合は、代わりに Azure AD テナントにアプリケーションを登録します。 また、登録によって、すべてのテナントでそのアプリを示す 2 つ目のアプリケーション オブジェクトも作成されます。

認証オプション

Key Vault の認証オプションは、Azure Active Directory (Azure AD) と連携して、セキュリティ プリンシパルの ID を認証します。
セキュリティ プリンシパルは、ユーザー、グループ、サービス、またはアプリケーションを表します。
Key Vault の認証オプションには以下のようなものがあります3:
- アプリケーションのみ: サービス プリンシパルまたはマネージド ID を使用します。
- ユーザーのみ: テナントに登録されている任意のアプリケーションからアクセスします。
- アプリケーションとユーザー (複合 ID): アプリケーションとユーザーの両方が必要です。
このオプションを使用するには、Azure AD でアプリケーションを登録し、ユーザーの委任された権限を付与する必要があります。また、Key Vault でアクセス ポリシーを設定し、アプリケーションとユーザーの両方に対して適切な権限を割り当てる必要があります

Key Vault の認証オプション

論理的削除

Azure Key Vault の論理的な削除の概要

–enable-purge-protection 引数がコンテナー自体で有効になっている場合。 この場合、Key Vault では、元のシークレット オブジェクトは、オブジェクトを完全に削除する削除対象としてマークされたときから 90 日間待機します。

論理的な削除と消去保護を使用した Azure Key Vault の回復の管理

すべてのキー コンテナーでの論理的な削除の有効化

消去

シークレットを完全に削除するには、2 つの操作を行う必要があります。
まず、ユーザーはオブジェクトを削除する必要があり、これによって論理的に削除された状態になります。
次に、ユーザーは論理的に削除された状態のオブジェクトを消去する必要があります。
消去操作には、追加のアクセス ポリシーのアクセス許可が必要です。
論理的に削除された状態のシークレットを消去するには、サービス プリンシパルに追加の “消去” アクセス ポリシーのアクセス許可が付与されている必要があります。
消去アクセス ポリシーのアクセス許可は、既定では、キー コンテナーとサブスクリプションの所有者を含むサービス プリンシパルには付与されないため、意図的に設定する必要があります。
論理的に削除されたシークレットを削除する際に昇格されたアクセス ポリシーのアクセス許可を要求することで、シークレットを誤って削除する可能性が減少します。

消去保護

消去保護

消去保護は Key Vault のオプションの動作であり、既定で有効になっていません。 消去保護は、論理的な削除が有効な場合にのみ有効にすることができます。

論理的な削除と消去保護を使用した Azure Key Vault の回復の管理

前提条件

消去保護は、悪意のある内部関係者によってキー コンテナー、キー、シークレット、証明書が削除されるのを防ぐように設計されています。
構成可能な保持期間中であればいつでも、項目を回復できます。
キー コンテナーは、保持期間が経過するまでは、完全に削除したり消去したりできません。
保持期間が経過すると、キー コンテナーまたはキー コンテナー オブジェクトは自動的に消去されます。

消去保護は、管理者のロールまたはアクセス許可によって消去保護を上書き、無効化、または回避することができないように設計されています。
Microsoft を含むすべてのユーザーは、いったん有効にされた消去保護は、無効にしたり上書きしたりできません。
つまり、キー コンテナー名を再利用するには、最初に削除されたキー コンテナーを回復するか、保持期間が経過するまで待つ必要があります。

Azure Key Vault のキー コンテナーを完全に削除する

PowerShell を使用して Azure の Key Vault を完全に削除する

復元

設計上の考慮事項

キー コンテナー オブジェクト (シークレット、キー、証明書など) をバックアップすると、そのオブジェクトは、バックアップ操作によって、暗号化された BLOB としてダウンロードされます。
Azure の外部でこの BLOB の暗号化を解除することはできません。
この BLOB から有効なデータを取得するには、同じ Azure サブスクリプションと Azure 地域内のキー コンテナーに BLOB を復元する必要があります。

Key Vault ファイアウォール

ファイアウォール設定

Key Vault ファイアウォールを有効にする (仮想ネットワーク - 動的 IP)

仮想ネットワーク内にリソースを作成し、特定の仮想ネットワークおよびサブネットからのトラフィックがご利用のキー コンテナーにアクセスするのを許可する必要があります

Azure Key Vault のネットワーク設定を構成する

  1. セキュリティで保護するキー コンテナーに移動します。
    2. [ネットワーク] を選択してから、 [ファイアウォールと仮想ネットワーク] タブを選択します。
    3. [許可するアクセス元] の [選択されたネットワーク] を選択します。
    4. 既存の仮想ネットワークをファイアウォールと仮想ネットワークの規則に追加するには、 [+ 既存の仮想ネットワークを追加] を選択します。
    5. 表示される新しいブレードで、このキー コンテナーへのアクセスを許可するサブスクリプション、仮想ネットワーク、サブネットを選択します。
    6. [IP ネットワーク] では、CIDR (Classless Inter-Domain Routing) 表記で IPv4 アドレスの範囲を入力して IPv4 アドレス範囲を追加するか、個々の IP アドレスを追加します。
    7. 信頼された Microsoft サービスが Key Vault ファイアウォールをバイパスすることを許可する場合には、[はい] を選択します。
    8. [保存] を選択します。

Azure Key Vault を作成する

信頼できるサービス

信頼できるサービス

ポリシー規則

Azure Key Vault と Azure Policy を統合する

キーのライフサイクル

Azure Storage

データ操作の承認

Azure Storage 内のデータへのアクセスを承認する

データ操作の認可について

※表参照

Azure Blob Storage の認証とアクセス制御

データプレーンの操作に対しては AAD 認証に加えて共有キーや SAS を利用した認証とアクセス制御が可能

ストレージ アカウント アクセス キー

ストレージ アカウント アクセス キーを管理する

ストレージ アカウント アクセス キーとは、Azure Storage に格納されたデータへのアクセスを認証するために使用される 512 ビットのキーのこと。
ストレージ アカウントごとに 2 つのキーが生成され、どちらか一方を使用してアクセスできます。

アクセスキーの管理には Azure Key Vault を使用し、キーのローテーションと再生成は定期的に行うことを推奨
Azure Key Vault を使用すると、アプリケーションを中断することなく簡単にキーをローテーションできます。 また、キーを手動でローテーションすることもできます

アクセス キーを手動でローテーションする

共有キーによる承認

Azure Blob Storage の認証とアクセス制御

ストレージアカウントのキーはストレージアカウントが作成されて初めて払い出されます。
つまり少なくともストレージアカウントを作成し、共有キーを払い出す操作に関しては Azure AD 認証を使用する必要があります。 このことからも「データプレーンの操作しか出来なさそうだな」ということが分かるかと思います。

なおストレージアカウントキー方式は最も古くから提供されている認証方式なのですが、現在では積極的な利用をあまりおススメしていません。 このキーを知っていればストレージアカウントのデータプレーンに対する任意の操作が可能ですので、権限が強すぎるというのが問題です。 アプリケーション設計時に認証方式に迷った場合は、原則として前述の AAD 認証か後述の SAS をご検討ください。

Azure AD と Azure RBAC による承認

BLOB データへのアクセスを認可するには、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、サービス プリンシパル (ユーザー、グループ、またはアプリケーション) にアクセス許可を割り当てる必要があります。

Azure Active Directory を使用して BLOB へのアクセスを認可する

Azure Storage では、Azure AD を使用して BLOB データへの要求を認可することがサポートされています。
Azure AD では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、サービス プリンシパル (ユーザー、グループ、またはアプリケーションのサービス プリンシパルである可能性があります) にアクセス許可を付与します。
セキュリティ プリンシパルは、Azure AD によって認証されて、OAuth 2.0 トークンを返します。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。

Azure AD を使用して認可すると、共有キーによる認可よりも優れたセキュリティと使いやすさが実現されます。 Microsoft では、必要最小限の特権でアクセスできるようにするために、可能な場合は BLOB アプリケーションで Azure AD の認可を使用することをお勧めします。

Azure Blob Storage の認証とアクセス制御

AAD でユーザーないしはアプリケーションを認証し、
そこで得られたアクセストークンを REST API に提示、
操作可否を RBAC で制御する方式

AAD 認証でデータプレーンにアクセスする
データプレーン用の操作なので、先ほどとは別の RBAC ロール割り当てが必要になります。
例えば下記では仮想マシンの Managed ID に対して、とあるリソースグループに対する ストレージ Blob データ共同作成者 ロールを割り当てています。
この Managed ID を使用するアプリケーションが、データプレーンの API を操作して Blob の書き込みや読み取りをする

共有アクセス署名 (SAS)

共有アクセス署名 (SAS) とは、Azure Storage リソースへの制限付きアクセス権を付与する URI
SAS を使用すると、ストレージ アカウント内のリソースへのセキュリティで保護された委任アクセスが可能になる
SAS には、アカウント SAS とサービス SAS の2種類がある

共有アクセス署名を使用してアクセスを委任する

共有アクセス署名 (SAS) は、Azure Storage リソースへの制限付きアクセス権を付与する URI です。
ストレージ アカウント キーで信頼する必要はありませんが、
特定のストレージ アカウント リソースへのアクセスが必要なクライアントには、共有アクセス署名を提供できます。
これらのクライアントに SAS URI を配布して、指定したアクセス許可セットで、指定した期間、リソースへのアクセスを許可できます。

Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する

SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。 次に例を示します。
・ クライアントがアクセスできるリソース。
・ それらのリソースに対するアクセス許可。
・ SAS が有効である期間。

アカウント キーを使用して SAS トークンに署名する

サービス SAS とアカウント SAS は、どちらもストレージ アカウント キーを使用して署名されます。

AzureのSAS（共有アクセス署名）を分かりやすく解説する

Azure Blob Storage の認証とアクセス制御

SAS : Shared Access Signature 方式も事前にクライアントにキー（のようなもの）を共有する方式なのですが、 Blob やコンテナといった限定的なスコープに対して、Read のみとか、IP アドレス制限、時間制限 といったきめ細かなアクセス制御が可能です。
AAD 認証を使ったデータアクセスが難しいなどの制約がある場合は、ストレージアカウントキーではなくこちらの SAS キーを使用すると良いでしょう。

アカウント SAS

ストレージ アカウント内の複数のサービスへのアクセスを一度に委任する。
サービス SAS を使用して実行できるすべての操作は、アカウント SAS でも実行できる
サービス SAS で許可されていない BLOB コンテナー、テーブル、キューおよびファイル共有の読み取り、書き込みおよび削除操作へのアクセスも委任できる

※保存されているアクセス ポリシーは、現在、アカウント SAS ではサポートされていません。

アカウント SAS を作成する

共有アクセス署名SASを利用したストレージアクセス

サービス SAS

Azure Blob Storage、Azure Queue Storage、Azure Table Storage、Azure Filesのいずれかのストレージ サービス内のリソースへのアクセスを委任する

保存されているアクセス ポリシー

保存されているアクセス ポリシーの定義

格納されたアクセス ポリシーは、サーバー側のサービス SAS に対する追加のレベルの制御を提供
格納されたアクセス ポリシーを設定することで、SAS をグループ化し、ポリシーによって規定されたパラメーターで SAS を管理できる

注意
コンテナーに格納されているアクセス ポリシーは、コンテナー自体またはコンテナーに含まれる BLOB にアクセス許可を付与する共有アクセス署名に関連付けることができます。
同様に、ファイル共有に格納されているアクセス ポリシーは、共有自体またはファイルに対するアクセス許可を付与する共有アクセス署名に関連付けることができます。

保存されているアクセス ポリシーは、ユーザー委任 SAS またはアカウント SAS ではサポートされていません。

保存されているアクセス ポリシーを変更または取り消す

格納されているアクセス ポリシーを取り消すには、そのポリシーを削除するか、署名付き識別子を変更して名前を変更するか、有効期限を過去の値に変更します。

BLOB ストレージのスケール ターゲット

BLOB コンテナーごとの保存されるアクセス ポリシーの最大数 5

Storage Explorer

Storage Explorer の概要

Microsoft Azure Storage Explorer は、Windows、macOS、Linux での Azure Storage データの操作を容易にするスタンドアロン アプリ

暗号化

保存データに対する Azure Storage 暗号化

暗号化キー

Azure Storage では、Microsoft のマネージド キー を利用してストレージ アカウント内のデータを暗号化することも、カスタマー マネージド キー で暗号化を管理することもできます

暗号化キーの管理について

Microsoft のマネージド キー

既定では、新しいストレージ アカウント内のデータは Microsoft マネージド キーで暗号化されます

カスタマー マネージド キー

Blob Storage と Azure Files でデータの暗号化と復号に使用する目的で “カスタマー マネージド キー” を指定できます

Azure Key Vault に既存のストレージ アカウントのカスタマー マネージド キーを構成する

新規または既存のキー コンテナーを使用して、カスタマー マネージド キーを格納することができます。
ストレージ アカウントとキーコンテナーは、同じテナント内の異なるリージョンまたはサブスクリプションに存在する場合があります。

カスタマー指定のキー

Blob Storage でデータの暗号化と復号に使用する目的で “カスタマー指定のキー” を指定できます

暗号化スコープ

BLOB ストレージの暗号化スコープ

Azure Storage Analytics

Storage Analytics

Azure Storage Analytics ログ

Azure Storage Analytics ログを有効にして管理する (クラシック)

診断ログは、ストレージ アカウントの $logs という名前の BLOB コンテナーに保存されます。
ログ データを表示するには、Microsoft Azure Storage Explorer などのストレージ エクスプローラーを使用するか、プログラムによってストレージ クライアント ライブラリまたは PowerShell を使用します。

不変ストレージ

不変ストレージを使用してビジネスに不可欠な BLOB データを保存する

Azure Blob Storage の不変ストレージを使用すると、ユーザーはビジネスに不可欠なデータを WORM (Write Once, Read Many) 状態で保存できます。
WORM の状態では、ユーザーが指定した期間、データを変更および削除できません。
BLOB データに 不変ポリシー を構成することにより、上書きや削除からデータを保護することができます。

不変ポリシー

BLOB データに不変ポリシーを構成することにより、上書きや削除からデータを保護することができます。
不変性ポリシーには、時間ベースの保持ポリシー と 訴訟ホールド が含まれています。

バージョンレベル

BLOB バージョンに対する不変性ポリシーを構成する

コンテナレベル

コンテナーの不変性ポリシーを構成する

時間ベースの保持ポリシー

訴訟ホールド

プライベート エンドポイント

Azure Storage のプライベート エンドポイントを使用する

Azure Storage ファイアウォールおよび仮想ネットワークを構成する

Storage Explorer

Storage Explorer の概要

暗号化スコープ

BLOB ストレージの暗号化スコープ

暗号化スコープを使用すると、異なる顧客が所有する、同じストレージ アカウントに存在するデータの間にセキュリティで保護された境界を作成できます。

Azure Firewall

Azure Firewallの設定手順のご紹介

Azure Firewallを作成しただけでは、仮想マシンの送信／受信の通信はファイアウォールを経由してくれないため、独自のルーティング規則を定義するための「ルートテーブル」のリソースを作成していきます。

Firewall ポリシー

ポリシー ルール セット

Azure Firewall ポリシー ルール セット

ルール コレクション グループ

DNAT ルール コレクション グループ

ネットワーク ルール コレクション グループ

アプリケーション ルール コレクション グループ

ルール コレクション

DNAT ルール コレクション

ネットワーク ルール コレクション

アプリケーション ルール コレクション

ルール

DNAT ルール

DNAT ルール

DNAT ルールは、ファイアウォールのパブリック IP アドレスを介した受信トラフィックを許可または拒否します。
パブリック IP アドレスをプライベート IP アドレスに変換する場合は、DNAT 規則を使用できます。
Azure Firewall のパブリック IP アドレスを使用して、インターネットからの受信トラフィックをリッスンし、トラフィックをフィルター処理して、このトラフィックを Azure の内部リソースに変換できます。

ネットワーク ルール

ネットワーク ルール

アプリケーション ルール

アプリケーション ルール

Azure Storage Explorer

Azure Storage Explorer

Azure Storage BLOB、ファイル、キュー、テーブルに加えて、Azure Data Lake Storage エンティティと Azure マネージド ディスクのアップロード、ダウンロード、管理を行うことができます。
ストレージのアクセス許可とアクセス制御、階層、規則を構成できます。

Storage Explorer の概要

Microsoft Azure Storage Explorer は、Windows、macOS、Linux での Azure Storage データの操作を容易にするスタンドアロン アプリ

Azure VM

Azure Instance Metadata Service

Azure Instance Metadata Service

イメージ

Azure Marketplace

Azure PowerShell を使用して Azure Marketplace VM イメージを検索して使用する

Set-AzMarketplaceTerms

特定のパブリッシャーID（パブリッシャー）、オファーID（製品）、およびプランID（名前）の条件に同意または拒否します。Get-AzMarketplaceTermsを使用して、契約条件を取得してください。

Azure Disk Encryption

Azure Disk Encryption では、Azure Key Vault を使用して、ディスク暗号化キーとシークレットを制御および管理

Windows VM 用の Azure Disk Encryption

Linux VM に対する Azure Disk Encryption

Azure Disk Encryption は、Basic、A シリーズ VM または次の最小メモリ要件を満たしていない仮想マシンでは利用できません。

Windows VM で Azure Disk Encryption のキー コンテナーを作成して構成する

警告
暗号化シークレットがリージョンの境界を越えないようにするには、暗号化する VM と同じリージョンとテナントにキー コンテナーを作成して使用する必要があります。

キー コンテナーに高度なアクセス ポリシーを設定する

Azure プラットフォームには、Key Vault 内の暗号化キーまたはシークレットへのアクセス権を付与する必要があります。
これにより、ボリュームをブートして暗号化する際に、それらの情報を VM に提供できるようになります。

Azure Disk Encryption 用キー コンテナー

Key Vault 内の暗号化キーまたはシークレットへのアクセス権を付与する必要があります。
これにより、ボリュームをブートして暗号化する際に、それらの情報を VM に提供できるようになります。
作成時に ディスクの暗号化、デプロイ、またはテンプレートのデプロイに対してキーコンテナーを有効にしなかった場合は、その高度なアクセスポリシーを更新する必要があります。

仮想マシン拡張機能

Azure 仮想マシンの拡張機能とその機能

Key Vault VM 拡張機能

Key Vault VM 拡張機能では、Azure キー コンテナーに保存されている 証明書 の自動更新が行われる

Linux 用の Key Vault 仮想マシン拡張機能

Windows 用の Microsoft マルウェア対策拡張機能

Windows 用の Microsoft マルウェア対策拡張機能

マルウェア対策のデプロイ シナリオ

Azure Desired State Configuration 拡張機能ハンドラー

Azure Desired State Configuration 拡張機能ハンドラーの概要

Azure の望ましい状態の構成 (DSC) 拡張機能の主なユース ケースは、VM を Azure オートメーション状態構成 (DSC) サービスにブートストラップすることです。
このサービスには、VM 構成の継続的な管理や、Azure 監視などの他の運用ツールとの統合などの利点があります。
拡張機能を使用して VM をサービスに登録すると、Azure サブスクリプション間でも機能する柔軟なソリューションが提供されます。

Azure Diagnostics 拡張機能

Azure Diagnostics 拡張機能の概要

Azure Diagnostics 拡張機能は、仮想マシンを含む Azure コンピューティング リソースのゲスト オペレーティング システムから監視データを収集する、Azure Monitor のエージェントです。

Linux Diagnostic Extension 4.0 を使用して、メトリックとログを監視する

Log Analytics 仮想マシン拡張機能

Windows 用の Log Analytics 仮想マシン拡張機能

Azure 仮想マシンに Log Analytics エージェントがインストールされ、仮想マシンが既存の Log Analytics ワークスペースに登録されます。

VM 再デプロイ

新しい Azure ノードへの Windows 仮想マシンの再デプロイ

VM を再デプロイすると、Azure では VM がシャットダウンされ、Azure インフラストラクチャ内の新しいノードに VM が移動されてから、電源が再びオンにされて、すべての構成オプションと関連するリソースが保持されます

可用性セット

可用性セットの概要

更新ドメイン

障害ドメイン